Hi Ana,I'm glad you could get the benchmarks to work! In principle, your implementation of setting the domain markers should work. But, in your spatialparams_1p_fracture.hh in the permeability() function, you return a reference to a temporary object. That is, your return type is "PermeabilityType&" but your return statement is "return 1e4". A simple and quick fix is to remove the "&" from your return type specification. Then it works!
But, I think there is a more elegant way of using domain markers. The grid data object that can be obtained from the FacetCouplingGridManager is some sort of meta-grid-data, which you have used correctly. But, it also allows for extraction of the actual grid data objects of the different subdomains. Those can then be used within subdomain context in the exact same way as you would in uncoupled models.
I slightly modified your application in order to test it on my machine, and I added the code to this mail in case you want to have a look at it. The main file is adjusted such that the fracture domain's grid data is obtained from the grid manager and is then passed to the fracture spatial parameters' constructor instead of calling your function "setElemMarkers". I deleted that function from spatialparams_1p_fracture.hh, and instead, I adjusted the constructor to receive grid data is well. This is then used to check the marker of an element within the permeability() function.
I also added the domain markers to the fracture vtk output as I wanted to check if the output is correct.
I think the fracture exercise of the dumux course also uses and discusses domain markers, so maybe you also want to have look in there: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/tree/master/exercises/exercise-fractures
I hope this helps! Best wishes, Dennis On 12.10.20 15:22, Ana Carolina Loyola wrote:
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, AnaEm sáb., 3 de out. de 2020 às 06:34, Dennis Gläser <[email protected] <mailto:[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 list [email protected] <mailto:[email protected]> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
<<attachment: benchmark3_v2.zip>>
_______________________________________________ DuMux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
