yade-dev team mailing list archive

[Luc Scholtes <lscholtes63@xxxxxxxxx>]

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 <bruno.chareyre@xxxxxxxxxxxxxxx>
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     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>