← Back to team overview

yade-dev team mailing list archive

[Bug 1734653] Re: DFN+fluid compressibility not using the correct reference volume

 

You are right, we probably mixed up a few things... Sorry for that.

If the main question concerns the reference volume Vo, here is my
understanding of your proposals:

1 - Vo=matrixPorosity*cellVolume for a cell in the intact matrix 
2 - Vo=aperture*area+matrixPorosity*cellVolume for a cell cut by a pre-existing fracture (DFN). 

In the latter case, jointInitialAperture and slotInitialAperture (or,
more generally, residual aperture) are the right candidates for aperture
(as suggested in your first message). There should not be any problem
with aperture being equal to zero because of the
+matrixPorosity*cellVolume.

Q1 - How do we deal with multiple prefractured edges? DFNs usually
correspond to individual fracture planes which would respectively cross
1 or 2 edges of the facet. Also, several fracture planes can eventually
cross the same facet with different orientations. If we forget the
multiple planes configuration for the moment, aperture should be equal
to 1*residualAperture even if 2 edges are concerned (no additivity),
right? If you agree on this, then, we need to think about the area ->
Q2.

Q2 - What about the area? Right now, conductivity is computed assuming
squared parallel plates with reference length equal to the distance
between the connected cells centers. Related to Q1, area should be
"weighted" by the number of fractured edges, right? Using triangular
surfaces joining the middle of the edge and the cell centers would
probably be ideal with respect to the geometry of our problem but then
the cubic law used for computing the conductivity would be kind of
flawed, right? What about associating rectangular plates of dimensions
0.5*cell1CenterToCell2Center*middleOfBrokenEdge1ToMiddleOfBrokenEdge2 to
each edges? The conductivity would then be adapted correspondingly to
the number of fractured edges.

Q3 - Should we consider cellVolume as V(tetrahedron) or as
V(tetrahedron)-V(spheres)? I guess it depends on how we compute dV=V-Vo.
If V=V(tetrahedron) then cellVolume=V(tetrahedron), right?

Q4 - How do we define matrixPorosity? Any chance that we could relate
matrixPorosity to the permeabilityFactor used to scale down the overall
permeability or do we simply relate to the porosity of the material?
This is probably stupid to relate permeability to porosity but I am
asking because it is sometimes difficult to have the data.

Q5 - If statement 2 is confirmed, do we need to take into account the
induced cracks contribution to V in the calculation of dV=V-Vo?

Luc

-- 
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 is mainly due to cracks, i.e. it is much smaller than the numerical porosity calculated between spheres.
  Typically V=opening*area+matrixPorosity*cellVolume
  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


References