Hi Nikolai,
the syntax is almost correct, but the grid id is the wrong type. You can
obtain it from the grid manager, I suggest the following (I am assuming
you have an alias defined for the grid manager and the fracture grid
index type):
auto embeddingsPtr = gridManager.getEmbeddings();
std::vector<FractureGridIndexType>
gridIndexToInsertionIndex(fractureFvGridGeometry->gridView().size(0));
for (const auto& element : elements(fractureFvGridGeometry->gridView()))
gridIndexToInsertionIndex[fractureFvGridGeometry->elementMapper().index(element)]
= embeddingsPtr->template insertionIndex<GridManager::bulkGridId>(element);
I hope this works!
Best wishes,
Dennis
On 13.12.18 18:46, Nikolai Andrianov wrote:
Hi Dennis,
What is the exact syntax of calling the insertionIndex?
I try the following, but get the comilation errors (Dumux finds no no
matching function to the call of insertionIndex):
auto embeddingsPtr = gridManager.getEmbeddings();
const int bulkGridId = 0;
for (const auto& element :
elements(fractureFvGridGeometry->gridView()))
const auto ind = embeddingsPtr->template
insertionIndex<bulkGridId>(element);
Thanks,
Nikolai
------------------------------------------------------------------------
*From:* Gläser, Dennis <[email protected]>
*Sent:* Thursday, December 13, 2018 4:04:31 PM
*To:* Nikolai Andrianov; DuMuX User Forum
*Subject:* AW: Variable fracture aperture
Hi Nikolai,
in the facet coupling framework there is actually a way to obtain the
insertion index of an element, which would correspond to the index of
the element in the gmsh file. However, you gmsh often starts with the
index 1 so be careful to subtract this here.
In the facet coupling framework the data on which lower-dimensional
elements are coupled to which bulk element are obtained directly from
the mesh file. This data can be accessed in the grid manager, i.e. by
typing gridManager.getEmbeddings().
However, these embeddings are in gmsh indices (as they come from the
gmsh file). Thus, the embeddings also provide an interface
insertionIndex(const Element&) so that the embeddings can be
translated into dune grid indices.
So, if you want to obtain an insertion (=gmsh) index of an element,
you can do so e.g. in the main file after calling gridManager.init()
and obtaining the embeddings. You could for example then set up a
vector of apertures in grid indices by converting insertion to grid
index and pass this vector to your sub-problem.
Kind regars,
Dennis
------------------------------------------------------------------------
*Von:* Nikolai Andrianov <[email protected]>
*Gesendet:* Donnerstag, 13. Dezember 2018 15:43:11
*An:* Gläser, Dennis; DuMuX User Forum
*Betreff:* RE: Variable fracture aperture
Hi Dennis,
Thanks for your feedback!
The domain marker in Dumux refers to the number of Physical Line() in
gmsh, so you suggest to create a number of Physical Line’s in gmsh so
that each of them could be assigned some specific aperture.
I actually would like to keep the number of Physical Line’s limited so
that each Physical Line could be assigned some other specific
parameter, say porosity. However, I would like to be able to change
aperture for every low-dimensional fracture element (i.e. there would
be several apertures for the same Physical Line).
Is there a way to get the original gmsh index of the low-dimensional
elements from the GridData object?
Thanks,
Nikolai
*From:* Gläser, Dennis <[email protected]>
*Sent:* Thursday, December 13, 2018 09:44
*To:* DuMuX User Forum <[email protected]>; Nikolai
Andrianov <[email protected]>
*Subject:* AW: Variable fracture aperture
Hi Nikolai,
you can have a look at the fracture exercise in the DuMuX course:
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/tree/master/exercises/exercise-fractures
Therein, we use the Gmsh domain markers to distribute fracture
apertures. The explanation would be a bit lengthy and I guess you can
find all the information you need within the exercise description. The
main concept is to use the GridData object from the GridManager. In
the main file of the exercise you can see how this data is retrieved
and then passed to the sub-problems and spatial parameters classes.
In short words, in Gmsh you can assign an index (domain marker) to
each fracture line (2d domain) or fracture surface (3d domain). All
elements that lie on the line/surface will then get this domain marker
in the mesh file and it is possible to retrieve this again in DuMuX.
Rergarding you question of the interface. As for the other parameter
interface functions, for the extrusion factor there is also the
version with the suffix AtPos(), but there is also the version taking
element/scv/elemsol (see fvproblem.hh):
template<class ElementSolution>
Scalar extrusionFactor(const Element& element,
const SubControlVolume& scv,
const ElementSolution& elemSol) const
{}
Note that the element index alone is not enough to distribute your
parameters because depending on the grid manager (ALUGrid, UG, ...),
the indices might not be equal to the order of the .msh file. You
would need the insertion index of the element. The way to go are the
domain markers I would say.
I hope this helps!
Best wishes,
Dennis
------------------------------------------------------------------------
*Von:*Dumux <[email protected]
<mailto:[email protected]>> im Auftrag von
Nikolai Andrianov <[email protected] <mailto:[email protected]>>
*Gesendet:* Mittwoch, 12. Dezember 2018 18:40:21
*An:* DuMuX User Forum
*Betreff:* [DuMuX] Variable fracture aperture
Dear DuMuX experts,
Please advise what is the best way to assign variable fracture
aperture for a multidomain/fracture flow application.
I would like to have apertures be pre-computed and read by DuMuX from
an external file, so that the fracture apertures correspond to the
numbering of fracture elements in the gmsh mesh file.
Currently the apertures are read via extrusionAtPos(const
GlobalPosition& globalPos) in the fractureproblem.hh. It would be
great if I could get not the position of the element’s center as
parameter, but say the corresponding SubControlVolume which apparently
does have the elementIndex. But how can I do this without modifying
dumux/common/fvproblem.hh ?
Thanks,
Nikolai
_______________________________________________
Dumux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
