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: [email protected]
D-70569 Stuttgart             url: www.iws.uni-stuttgart.de/en/lh2/
_________________________________________________

> On 25. Mar 2020, at 18:39, Dmitry Pavlov <[email protected]> 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
> [email protected]
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

_______________________________________________
Dumux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Reply via email to