Thank you Dennis, this was very helpful. I have been working on the other benchmarks since your response and they all work fine. But on benchmark 3, which contains both blocking and conductive fractures I could only define the permeability of the fractures based on their locations using the function permeabilityAtPos() . For that I had to define the coordinates of the blocking fractures, which was fine for this small problem but I'd rather define the permeability based on the domain markers. How can I do that easily in version 3.2 ? Is there any example that does this ?
I tried to do so by defining a map elemMarkers which maps elements ids and
their domain markers, and setting it at the template function
setElemMarkers(GridManager), which receives the grid manager as an argument:
template <class GridManager>
void setElemMarkers(GridManager gridManager)
{
auto gridData = gridManager.getGridData();
const auto& fractureGridView = gridManager.template
grid<1>().leafGridView();
elemMarkers.resize(fractureGridView.size(0));
for (const auto& element : elements(fractureGridView))
{
const auto eIdx =
this->gridGeometry().elementMapper().index(element);
int marker = gridData->template
getElementDomainMarker<1>(element);
elemMarkers[eIdx] = marker;
}
}
and then I overload the template function permeability to return the
permeability based on the element marker. But that causes a segmentation
problem because the volume variables class does not seem to be able to
enter this overloaded function. I am sending the files but I am not sure
you will need it since there is probably a more straight-forward way to do
this.
Thanks a lot.
Best regards,
Ana
Em sáb., 3 de out. de 2020 às 06:34, Dennis Gläser <
[email protected]> escreveu:
> Dear Ana,
>
> we are happy to hear that you are interested in the benchmark studies and
> and the fracture module of Dumux!
>
> One thing in advance: In the paper that you are referring to (Flemisch et
> al. (2018)), the "*box-scheme*" for which results are presented in the
> paper, is not the scheme that you are using in the code snippet you sent. I
> guess you copied the code from the pub-module of the current follow-up
> paper (Flemisch et al. (2020)) that is soon to be published, in which we
> used the new fracture module of Dumux. The box-scheme featured in Flemisch
> et al. (2018) is still part of Dumux and if you want to learn how to use
> it, you can have a look at the following test:
>
>
> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/porousmediumflow/2p/implicit/boxdfm
>
> Unfortunately, this test is for two-phase flow and we currently have no
> single-phase test with this scheme. The simplification to single-phase flow
> should be straightforward, though.
>
> Regarding you first question: the multidomain assembler does actually
> assemble the system in a fully coupled way, and the equations are not
> nonlinear in your application. The only reason why one needs more than one
> Newton iteration is that the derivatives that go into the global system
> matrix are computed numerically, and thus, they are not exact. However, it
> should only take two Newton iterations (for the chosen BaseEpsilon in the
> params.input file).
>
> The reason why your applications does not seem to converge is something
> related to the grid you use. I didn't really dig into what is the issue
> there, but it seems that the coupling entries for some bulk-fracture
> interfaces are not deduced from the mesh (maybe some lines are defined
> twice or so?). This possibly leads to floating 2d subdomains that are fully
> bounded by Neumann boundary conditions - as the coupling to the surrounding
> fractures is not seen.
>
> I just tested it with a self-made gmsh file and it worked straight away. I
> attached a slightly modified version of your application to this mail,
> which works with the current Dumux master, and also defines applications
> using tpfa, mpfa and box - so, all schemes available in Dumux. Moreover, it
> contains the corrected .geo file.
>
> I hope this helps!
>
> Best wishes,
> Dennis
>
>
>
> On 01.10.20 11:49, Ana Carolina Loyola wrote:
>
> Hi,
>
> I am starting to get familiarized with the solution of one-phase flow in
> fractured media in Dumux 3.2. I started by trying to simulate the first
> benchmark proposed in Flemisch et al (2018) (reference below) witht he Box
> and the Ctpfa methods. The paper used a preivous version of Dumux, when
> the multidomain coupling manager did not exist.
>
> It is a 2d domain containning a regular fracture network (gmsh file is
> attached). I used an example in Dumux-pub and basically only changed the
> dimension of the domain from 2d to 3d and altered the boundary conditions
> (project is attached).
>
> First of all, I have a question about the multidomain assembler. It deals
> with the two domains by solving the fracture and the matrix domains
> separetely, treating the jacobian and solution vectors as block structures,
> which makes this stationary problem non-linear. This led me to convergence
> issues, since the Box method does not converge for any of the meshes I
> tested. *Is there the possibility of handling this problem in a fully
> coupled way ?* that is, making the multi-domain assemblage so I have only
> one matrix where the nodes which contain both fracture and matrix have the
> contributions of both domains added up. This way I would not need a
> non-linear solver. Any function to do that while maintaining the
> multi-domain context ?
>
> If not, I would like to hear some insights, if you have any, on what may
> be causing the non-convergence of the bok method. I use the UMFPackBackend
> linear solver and I have tried many other finer and coarser meshes.
>
> Reference:
> Flemisch, B., Berre, I., Boon, W., Fumagalli, A., Schwenck, N., Scotti,
> A., Stefansson, I., Tatomir, A., 2018. Benchmarks for single-phase flow in
> fractured porous media. Advances in Water Resources. 111, 239–258.
>
> Thank you.
>
> Best regards,
>
> Ana
>
>
>
>
> _______________________________________________
> DuMux mailing
> [email protected]https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
>
>
benchmark3.rar
Description: Binary data
_______________________________________________ DuMux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
