Hi guys, I have done some testing this summer on that aspect which might be useful for the discussion. The incremental increase of permeability is certainly more "accurate" but it does not change much the simulated behavior (I am again talking about the stress induced permeability changes I mentioned in another thread). If you remember, one of the concerns we had about the computation of the local permeability was that the increase of macroscopic permeability of damaged samples occurs too early with the current implementation. I did test the incremental solution and the results are actually very similar to the non incremental ones... Probably because we are dealing with several order of magnitudes of permeability change. This is a bit tricky but we have to keep in mind that stress induced cracks are not "connected" one with another up until a fair amount of them is present inside the medium (crack coalescence can be observed sometimes only after 70% of the peak stress has been reached while isolated cracks can appear at less than 20% of the stress peak). Triggering interporal permeability changes to all pores concerned with the cracked edges is, IMO, not adapted, not to every (most?) types of rock materials. I must say that the (questionable) solution consisting in waiting for at least 2 edges of a facet to be cracked before triggering the local permeability change of the corresponding facet gives better results because it somehow delays the macroscopic permeability change...
I'll try to summarize my results asap. Let's keep the discussion here but we might find it easier to go through direct phone calls or visionconferences. Up to you. Luc Le lun. 3 sept. 2018 à 10:44, Bruno Chareyre <[email protected]> a écrit : > Hi Robert, > It sounds good, except that I would increment kNorm directly instead of > incrementing a counter. > Logic: > - two adjacent cracks cumulate their conductivity: Ktot = K1+K2 > - if you accumulate aperture you get (a1+a2)^3 instead of (a1^3 + a2^3), > it will increase to much it seems. > > I know there can still be some form of non linearity depending on the > count but the cube of the sum is to much IMO. > > Bruno > > On 09/02/2018 03:39 PM, Robert Caulk wrote: > > Hello, > > I am working on a check test for DFNFlow in which I use pressure and > aperture as pass criteria. However, I want this check script to be a > repeatable baseline for DFNFlow, so I'd like to remove/replace the existing > uncertainty associated with tricking permeability. If this change may > affect you, please review the following and reply with your > comments/suggestions. > > *Existing problem:* > Currently, DFNFlow tricks facet permeability by using the most recently > visited edge, which means the tricked facet permeability has no physical > basis, in fact, it depends on the order of the C++ for loop. > > *Discussed solution:* > Luc, Timos, Bruno, and I discussed this a bit in Aix-en-Provence and > agreed(?) that we should increment the total aperture of a facet for every > broken edge associated with that facet. In other words, if one facet has 2 > broken edges, the aperture used to trick facet permeability is the > summation of both apertures (instead of the most recently visited edge > during tickPerm loop). Thus, the aperture incrementation method has some > physical basis and no longer depends on the order of C++ for loop. > > If we want/need to keep the uncertain trickPerm method around, let me know > and I will add a flag for you. > > *Proposed changes to DFNFlow.cpp [1]:* > > DFNFlow.cpp around line 245: > > // increment the facet's aperture member: > if (cell1->info().count()[currentFacet.second] < 3){ > cell1->info().count()[currentFacet.second] += 1; > cell1->info().aperture()[currentFacet.second] += aperture; > } > > // use the incremented facet aperture member to update facet permeability: > cell1->info().kNorm()[currentFacet.second] = > cell2->info().kNorm()[Tri.mirror_index(cell1,currentFacet.second)] = > apertureFactor*pow(cell1->info().aperture()[currentFacet.second],3)/(12*viscosity); > > *Status:* > I used this method for creating the DFNFlow check script - the code is > stable and produces repeatable pass criteria. > > Cheers, > > Robert > > [1]https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
