-- _________________________________________________ Timo Koch phone: +49 711 685 64676 IWS, Universität Stuttgart fax: +49 711 685 60430 Pfaffenwaldring 61 email: timo.k...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ _________________________________________________
> On 26. Mar 2020, at 17:37, Dmitry Pavlov <dmitry.pav...@outlook.com> wrote: > > Dear Timo, > > >> depends on what you understand under outflow. > In the problem I am trying to model, I have one injection well and one > production well. The wells are essentially boundaries of a 2D rectangle. > Water is injected on one boundary, while oil+water mix is extracted on the > opposite one. I was thinking of setting on the production well a constant > pressure and zero relative saturation derivative (dSn/dx = 0, which of course > implies dSw/dx = 0). So this is a combination of Dirichlet for pressure and > Neumann for saturation. I am not quite sure that this is the best way to > model this sort of thing. If you have your thoughts, I would appreciate them. > I do not think that I can fix the saturation on the production well, because > I am studying a nonstationary situation in which water gradually pushes out > oil. > > >> For Neumann what we expect from the function “neumann” in the problem class >> that it returns a boundary flux for both equations (NumEqVector). By “flux" >> I mean the entire term in the divergence. > > Sorry, I am having trouble understanding how that can be applied to the term > with the saturation. But since I currently want to set it to zero, probably > it does not matter. > Hi Dmitry, you have to return the normal flux term or what is left from it after inserting gradS*n = 0. That depends on which equation you are looking at, and what primary variables you have. The flux term in the assembled equation (as you can see in the doc) contains grad(p_w) or grad(p_n). If you want to set something for S_w or S_n you first have to figure out (by using p_c = p_n - p_w, and S_w = S_w(p_c)) what the term looks like in terms of the saturation or its spatial derivatives. Then insert your boundary conditions (pen&paper), and the left-over part has to be assembled as the boundary normal flux. I guess gradS*n = 0 doesn’t necessarily mean that the pressure gradient is also zero, but I haven’t thought about it in detail. >> AFAIK, if you want some mixed Dirichlet/Neumann condition, i.e. fix the >> pressure + enforce a flux for the second equation, you need to convert the >> Dirichlet condition to a Robin condition and implement it in “neumann”. > > Yes, so I was told by DuMux: "Mixed boundary conditions. Use pure boundary > conditions by converting Dirichlet BCs to Robin BCs". But how exactly do I do > that? I do not see this kind of thing in the examples (or I do not know what > to look for). Is it the addRobinFluxDerivatives() call that I should > implement somehow? I think you are using cell-centred TPFA. So Dirichlet boundaries are weakly enforced anyway. You fix (mentally or in the math) the Dirichlet values on the boundary face and then compute (implement) the normal flux using the cell-values and the boundary values in the neumann() function of the Problem class. You get the cell values in the neumann function as “const auto& volVars = elemVolVars[scvf.insideScvIdx()]” and then e.g. “volVars.pressure(phaseIdx)” or “volVars.saturation(phaseIdx)”. I don’t know a 2p example right now, but for example https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/richards/implicit/nonisothermal/evaporation/problem.hh <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/richards/implicit/nonisothermal/evaporation/problem.hh> implements an energy flux over the boundary like this. You can implement any boundary flux you want there. But there is unfortunately no “preimplemented boundary conditions” since the exact boundary flux highly depends on the considered scenario/application. If you have suggestion for a “standardized” boundary condition type that is very useful, feel free to open an issue or suggest an implementation as a merge request: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux>. Except of course Neumann no-flow (which is returning 0.0 in the Problem::neumann function) or Dirichlet (which is returning the Dirichlet values in the Problem::dirichlet function). addRobinFluxDerivatives() is only needed if you want to implement an exact / analytical Jacobian matrix for your problem. In the default setting DuMux computes the Jacobian using numerical differentiation and doesn’t need any user-implemented derivatives. Hope this helps Timo > > Best regards, > > Dmitry > > > > On 25.03.2020 22:10, Timo Koch wrote: >> Dear Dmitry, >> >> depends on what you understand under outflow. The outflow boundary condition >> is not implemented anymore for the implicit 2p model — exactly for the >> reason you mention: it’s not really clear what it means. >> I’m wondering why you don’t get an error. I’ll open an issue so that we look >> at that and that users get a better error message in the future. >> >> I guess you know better which condition you want in your example, but >> generally you have two options in Dumux: >> You can set Dirichlet (setAllDirichlet()), depending on your chosen >> formulation that means setting e.g. pn and Sw., or you can set Neumann/Robin >> (setAllNeumann). >> For Neumann what we expect from the function “neumann” in the problem class >> that it returns a boundary flux for both equations (NumEqVector). >> By “flux" I mean the entire term in the divergence. You can look at the >> documentation for the 2p model: https://dumux.org/doxygen/3.1/a18570.html >> <https://dumux.org/doxygen/3.1/a18570.html> for the equations implemented. >> >> AFAIK, if you want some mixed Dirichlet/Neumann condition, i.e. fix the >> pressure + enforce a flux for the second equation, you need to convert the >> Dirichlet condition to a Robin condition and implement it in “neumann”. >> Neumann in Dumux also includes “solution-dependent” fluxes (i.e. >> Robin/Cauchy-type boundary conditions). But depending on your setup, just >> setting one saturation to 0/1 at the outlet may also give you a good result. >> >> Best regards, >> Timo >> >> >> >> -- >> _________________________________________________ >> >> Timo Koch phone: +49 711 685 64676 >> IWS, Universität Stuttgart fax: +49 711 685 60430 >> Pfaffenwaldring 61 email: timo.k...@iws.uni-stuttgart.de >> <mailto:timo.k...@iws.uni-stuttgart.de> >> D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ >> <http://www.iws.uni-stuttgart.de/en/lh2/> >> _________________________________________________ >> >>> On 25. Mar 2020, at 18:39, Dmitry Pavlov <dmitry.pav...@outlook.com >>> <mailto:dmitry.pav...@outlook.com>> wrote: >>> >>> Dear Martin, >>> >>> Thank you! So I was not basing quite on the right model/example for my task. >>> >>> I changed the model to dumux/porousmediumflow/2p, and am now having another >>> problem with the outflow condition: setOutflow(Indices::saturationIdx). It >>> worked with the sequential model, however, to be honest, I do not quite >>> understand what it really means. I would have understood >>> (mathematically/physically) a Neumann condition that the derivative of the >>> saturation on the outlet boundary must be zero, but I suspect setOutflow is >>> a different thing, and I never saw a Neumann condition on saturation in >>> DuMux examples in any form. >>> >>> Anyway, setOutflow() seemed to work with the sequential model, but with the >>> implicit model, it immediately results in >>> Assemble: ... >>> dumux/dumux/discretization/cellcentered/tpfa/elementvolumevariables.hh:322: >>> int Dumux::CCTpfaElementVolumeVariables<GVV, false>::getLocalIdx_(int) >>> const ... Assertion `it != volVarIndices_.end() && "Could not find the >>> current volume variables for volVarIdx!"' failed. >>> >>> When I remove setOutflow(), and set e. g. Dirichlet conditions on both >>> ends, the assertion failure is gone, so I guess that setOutflow() causes >>> trouble. >>> Could you recommend how do I specify the outflow boundary condition in my >>> case? >>> >>> Best regards, >>> >>> Dmitry >>> >>> >>> On 25.03.2020 20:12, Martin Schneider wrote: >>>> Dear Dmitry, >>>> >>>> but then I don't see the point why you want to use a compositional model. >>>> Couldn't you simply use the dumux/porousmediumflow/2p model? >>>> >>>> Best regards, >>>> Martin >>>> >>>> On 25.03.20 18:02, Dmitry Pavlov wrote: >>>>> Dear Martin, >>>>> >>>>> Thank you for a quick reply. I am currently dealing with a two-phase >>>>> two-component Darcy flow of water and oil. Both liquids are >>>>> incompressible and have constant viscosity. Gravity, thermal transfer and >>>>> diffusion are not considered. Custom functions are provided for capillary >>>>> pressure, relative permeability for water, and relative permeability for >>>>> oil. Is more information needed? >>>>> Initially, I wrote my program basing on the example >>>>> test/porousmediumflow/2p/sequential/test_mpfa2p, and it worked; now I am >>>>> exploring the implicit method option. >>>>> >>>>> Best regards, >>>>> Dmitry >>>>> >>>>> >>>>> On 25.03.2020 19:50, Martin Schneider wrote: >>>>>> Dear Dmitry, >>>>>> >>>>>> the compositional models in Dumux take into account diffusion effects >>>>>> between the different fluid phases, >>>>>> which is why you can't use an immiscible fluidsystem. >>>>>> >>>>>> Could you maybe send some more details about your equations you want to >>>>>> solve >>>>>> and about the phases and components that are involved. >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> >>>>>> On 25.03.20 17:36, Dmitry Pavlov wrote: >>>>>>> Dear Martin, >>>>>>> >>>>>>> Following your advice, I decided to try an implicit model of my >>>>>>> problem, namely a PorousMediumFlowProblem, following the example in >>>>>>> tests/porousmediumflow/2pnc/implicit/diffusion. >>>>>>> >>>>>>> I managed to compile it, but am getting a runtime error upon the start >>>>>>> and, honestly, have no idea what to do about it. I will appreciate any >>>>>>> pointers. >>>>>>> For convenience, I will describe my task again. I am trying to simulate >>>>>>> a two-phase two-component flow on a 2D rectangular area with one border >>>>>>> being the influx and the opposite one being the outflow (setOutflow()). >>>>>>> Two other two borders are walls, of course, with setAllNeumann(). >>>>>>> The fluid system is realized as a TwoPImmiscible of two OnePLiquid-s. >>>>>>> The first of the liquids is the wetting phase, the second is the >>>>>>> nonwetting phase. >>>>>>> >>>>>>> Now, the error that I am getting is >>>>>>> >>>>>>> Dune reported error: Dune::InvalidStateException >>>>>>> [binaryDiffusionCoefficient:.../dumux/dumux/material/fluidsystems/2pimmiscible.hh:462]: >>>>>>> Binary diffusion coefficients of components are meaningless if >>>>>>> immiscibility is assumed >>>>>>> I never any "binary diffusion coefficients" directly in my files, so it >>>>>>> comes from the method. >>>>>>> >>>>>>> I have doubts about the following line of my program >>>>>>> values.setState(Indices::bothPhases); >>>>>>> which is present in dirichletAtPos(), neumannAtPos(), and >>>>>>> initialAtPos() implementation. I do not really understand what does >>>>>>> this setState() setting mean, so I kind of guessed. >>>>>>> >>>>>>> >>>>>>> Am I on the right path at all here? I can provide more details, of >>>>>>> course, if that helps to understand what is going on. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Dmitry >>>>>>> >>>>>>> >>>>>>> On 23.03.2020 20:59, Martin Schneider wrote: >>>>>>>> Dear Dmitry, >>>>>>>> >>>>>>>> most of the Dumux users are using the fully-coupled (implicit) models. >>>>>>>> The sequential methods have not really been further developed (at >>>>>>>> least the discretization schemes) >>>>>>>> over the last few years. >>>>>>>> >>>>>>>> However, if you want to use the MPFA-L method you have to use the >>>>>>>> sequential method. >>>>>>>> The implicit models only support the MPFA-O scheme. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Martin >>>>>>>> >>>>>>>> On 23.03.20 18:53, Dmitry Pavlov wrote: >>>>>>>>> Dear Martin, >>>>>>>>> >>>>>>>>> I guess not, I took the first one that worked, after numerous failed >>>>>>>>> attempts with other methods taken from random examples, though the >>>>>>>>> said attempts might have failed because of me being a non-experienced >>>>>>>>> user, and not because of the nature of the methods. Would you suggest >>>>>>>>> to use an implicit method instead? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Dmitry >>>>>>>>> On 23.03.2020 20:48, Martin Schneider wrote: >>>>>>>>>> Dear Dmitry, >>>>>>>>>> >>>>>>>>>> if I remember correctly, the sequential MPFA-L scheme requires that >>>>>>>>>> each vertex is surrounded by 4 quadrilaterals (in 2D). >>>>>>>>>> If this is not the case, the construction of interaction volumes >>>>>>>>>> fails. >>>>>>>>>> >>>>>>>>>> Is there any reason why you are using the sequential method? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> On 23.03.20 18:42, Dmitry Pavlov wrote: >>>>>>>>>>> Dear Kilian, >>>>>>>>>>> >>>>>>>>>>>> 1.) You should be able to use more recent versions of gmsh if you >>>>>>>>>>>> go to File -> Export. If you name your grid *.msh >>>>>>>>>>>> >>>>>>>>>>>> there will be an option to chose the older Version II ASCII >>>>>>>>>>>> format, readable by Dumux. >>>>>>>>>>> Thank you! >>>>>>>>>>>> 2.) Have you tried an unstructured grid with quadrilaterals? >>>>>>>>>>>> According to the header where the error comes from, >>>>>>>>>>>> only quadrilaterals are supported (at least, this is what some >>>>>>>>>>>> comments in the code suggest). You can force gmsh to >>>>>>>>>>>> use only quads (also unstructured ones). >>>>>>>>>>> I just tried an unstructured quad grid and got the same error. >>>>>>>>>>> However, a gmsh-generated structured quad grid went fine, which >>>>>>>>>>> means that there is no trouble with gmsh itself. >>>>>>>>>>> >>>>>>>>>>> Good news: using FVPressureTwoPAdaptive instead of >>>>>>>>>>> FvMpfaL2dPressureTwoP allowed me to use an gmsh-generated >>>>>>>>>>> unstructured grid (both triangular and quadrilateral). I am >>>>>>>>>>> wondering whether MPFA-L in DuMux "officially" requires a >>>>>>>>>>> structured quad grid. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> _______________________________________________ >>> Dumux mailing list >>> Dumux@listserv.uni-stuttgart.de <mailto:Dumux@listserv.uni-stuttgart.de> >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >>> <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> >> > _______________________________________________ > Dumux mailing list > Dumux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
