Ok, I finally got some time to digest this. Thank you for pointing this
out, Bruno, it may have pretty severe impacts on DFNFlow simulations.

In my opinion, we would just *add* the crack volume to the original pore
volume. Let me see if I can explain why I think this:

It seems we need to agree on how the crackArea and crackAperture are
computed for these volume calcs. Each cell is currently associated with a
unique crackArea [1], but I am unsure what the geometry of the current C++
lines represent [2]. I am particularly confused by [3]. I guess I need
someone to translate that for me.

If I were to imagine a plane that represents the crackArea, I would
probably change the existing code to look something like this:

if (calcCrackArea) {
    CVector edgeMidPoint = (
ed_it->first->vertex(ed_it->second)->point().point()
+ed_it->first->vertex(ed_it->third)->point.point() ) / 2;
    CVector v1 = edgeMidPoint - CellCentre1;
    CVector v2 = edgeMidPoint - CellCentre2;
    Real halfCrackArea = 0.25*sqrt(std::abs(cross_product(v1,
v2).squared_length()));
    cell1->info().crackVol += halfCrackArea*aperture
    cell2->info().crackVol += halfCrackArea*aperture;
}


Which would give us a  crack plane that looks like this following poorly
drawn figure:

[image: Inline image 1]

In this scheme, the volume of the crack (crackVol in code above) within a
cell is simply the sum of all halfCrackArea_i*aperture_i where i indexes
the broken edge. Then we can add this volume to the original pore volume.
It's as if we are artificially creating volume space that is not reflected
by the packing geometry. Which is kind of what this all boils down to,
right? Or maybe I am totally lost. If you guys think this is worth testing,
I will implement, test, and report back.

Cheers,

Robert


[1] https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp#L269
[2] https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp#L263
[3] https://github.com/yade/trunk/blob/master/pkg/pfv/DFNFlow.cpp#L266

On Wed, Dec 6, 2017 at 2:52 AM, Bruno Chareyre <email address hidden>
wrote:

> > we should use directly crackAperture*crackArea as Vo in dV/Vo, no?
>
> That's more or less what I wanted to suggest. I can't explain why I wrote
> that strange formula.
> However I also wanted to skip the calculation of crackAperture*crackArea,
> namely because there can be multiple cracks, as you point out.
> So my idea was to store the initial value of the numerical porosity in one
> cell (call it V(t=0)) and to define the cracked volume as the difference
> V(t)-V(t=0). It makes multiple cracks less a problem I think.
>
> However, an obvious problem of this is that it result in a reference
> equal to zero when the crack occurs, and we need to divide by this
> volume... that was the reason to introduce an initial amount of liquid
> via matrixPorosity (could also depend on slotInitialAperture). Just an
> idea anyway. The problem of fluid flow inside an advancing crack tip
> seems fundamentally tough... I can't imagine a perfect answer yet.
>
> Bruno
>
> --
> You received this bug notification because you are a member of Yade
> developers, which is subscribed to Yade.
> https://bugs.launchpad.net/bugs/1734653
>
> Title:
>   DFN+fluid compressibility not using the correct reference volume
>
> Status in Yade:
>   New
>
> Bug description:
>   In the basic PFV scheme the incremental change of density of a pore
>   fluid after a change of pore volume is dependent on dV/Vo where Vo is
>   the reference pore space within a tetrahedral cell [1], i.e.
>   V(tetrahedron)-V(spheres).
>
>   In DFNFlow "V" should reflect the fact that porosity may be mainly due
> to a crack an its opening.
>   Typically V=V(tetrahedron)-opening*area-matrixPorosity.
>   Currently it is using the same formula, hence overestimating the
> compressibility effect (because the DEM porosity is larger than a typical
> rock porosity). What should be the reference "opening" in above formula is
> to be clarified though, it has physical as well as numerical implications.
> Maybe slotInitialAperture is a candidate? Let you DFN people tell what it
> should be.
>
>   Note that the "dV" is less a problem because it is a difference
>   (independent on the choice of the reference volume), so the
>   incompressible scheme is not affected.
>
>   Bruno
>
>   [1]
>   https://github.com/yade/trunk/blob/master/pkg/pfv/FlowEngine.ipp.in#L439
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1734653/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>