Hi Dennis,

Thanks a lot for your comments.


The setting I want to model is waterflooding of a porous block, initially 
saturated with oil with Sn = 1 - Swr. To this end, I consider pressure BC with 
Pl > Pr, so that oil gets produces at the right boundary. I set Sw=1 at the 
left, and specify no saturation at the right, hoping that due to upwinding the 
right saturation value will be never used anyway. Now in order for the total 
velocity to be positive (so that the upwind cell is always the one at the left) 
I choose the p1s0 formulation with the prescribed negative oil pressure 
gradient, Pnr-Pnl < 0. Since pn is a primary variable now, the change in 
saturation (and, correspondingly, the capillary pressure) does not change my 
oil pressure gradient - which is exactly what I want.


You are right, water pressure gets a bit wild, but the regularized Brooks-Corey 
takes care of it 😊


Looking forward for your feedback.


Best regards,

Nikolai

________________________________
From: Dumux <[email protected]> on behalf of Dennis 
Gläser <[email protected]>
Sent: Monday, August 20, 2018 4:03:15 PM
To: [email protected]
Subject: Re: [DuMuX] Linear solver crashes in release mode, but not in debug 
mode


Hi Nikolai,


I just went through your code and also compiled and ran it. Here are a few 
comments:


As initial saturation you set the residual water saturation. This corresponds 
to maximum capillary pressures, which can get extremely high at this point. 
This leads to your initial water pressure being negative, actually -1.3e6. 
However, on the left boundary you set S_w = 1.0, which is actually out of the 
bounds of your pc-sw curve because you are considering Snr = 0.27031. It should 
still return useful pc values using Brooks-Corey I suppose. On the right side, 
you do not initialize the value for saturation, so it is probably some random 
value that is currently in your memory. This is something you should look into 
and think about what value you actually want to prescribe there. Maybe the 
initial saturation, i.e. no gradient?


Anyway, this large difference in capillary pressures on the left side leads to 
an influx of water which can affect your oil pressure as well. I am not sure 
what you expect as a result, but I didn't find it surprising at first. The 
capillary effects in this setup are very large.


Let me know if this helps you!

Dennis


On 20.08.2018 14:05, Nikolai Andrianov wrote:

Hi Dennis,


Thank you for your feedback.


I have fixed the bug in in my local 
dumux/porousmediumflow/2p/volumevariables.hh  as you suggested, but unless I 
keep my modifications to discretization/cellcentered/tpfa/darcyslaw.hh the 
Dirichlet BCs conditions look weird.


I have also updated the repository 
https://git.iws.uni-stuttgart.de/andrian/rate-sens-nofrac so that these results 
could be reproduced.


Attached are 3 screenshots:

  1.  my_current_pn.png: The pn field obtained with the modified darcyslaw.hh 
as described below (fixing the bug in volumevariables.hhdid not change the 
solution neither in pn nor in sw);
  2.  orig_darcyslaw.png: The original darcyslaw.hh (i.e. without the 
modifications described below), the bug in volumevariables.hh not fixed. 
Observe that the pn values at the left and the right boundaries are quite 
different from the ones I prescribe in the .input file - 1.1 bar at the left 
and 1 bar at the right.
  3.  orig_darcyslaw_bug_fixed.png:The original darcyslaw.hh and the fixed bug 
in volumevariables.hh. Still the pressure field is far from the expected one.


Looking forward for your feedback.


Thanks,

Nikolai

________________________________
From: Dumux 
<[email protected]><mailto:[email protected]>
 on behalf of Dennis Gläser 
<[email protected]><mailto:[email protected]>
Sent: Monday, August 20, 2018 11:29:48 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [DuMuX] Linear solver crashes in release mode, but not in debug 
mode


Hi Nikolai,


this should lead you directly to the commit where this was fixed:


https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/commit/1fb7860720c08942c4166070b27bb138815a1be5


By prescribing both pressure and saturation at a Dirichlet boundary, pn will be 
constant at the boundary. In fact it will be the prescribed pressure + the 
capillary pressure resulting from the given boundary saturation. So you should 
not need the changes to darcys law that you have made. However, as Timo 
mentioned already, when using a cell-centered scheme you will not see the exact 
boundary value in your vtu files.


I would strongly recommend you use the unmodified Darcy's law and make sure to 
cherry-pick the commit I mentioned or pull the newest dumux version. Hopefully 
this solves the issue!


Best wishes,
Dennis


On 20.08.2018 11:17, Nikolai Andrianov wrote:

Hi Dennis,


I just modified my local discretization/cellcentered/tpfa/darcyslaw.hh as 
follows near line 207:


            // Obtain inside and outside pressures
            //const auto pInside = insideVolVars.pressure(phaseIdx);
            //const auto pOutside = outsideVolVars.pressure(phaseIdx);

            Scalar pInside, pOutside;
            if (!scvf.boundary()) {

                // Inside the domain calculate the phase flux using phase 
pressures (with pn = pw + pc)
                pInside = insideVolVars.pressure(phaseIdx);
                pOutside = outsideVolVars.pressure(phaseIdx);
            }
            else {
                // Do not include the contributions from capillary forces for 
boundary fluxes
                //static_assert( (VolumeVariables::priVarFormulation() == 
TwoPFormulation::p0s1), "darcyslaw.hh: BC implemented for p0s1 formulation 
only!");       // uncommenting this yields an error
                // WARNING: implemented for p1s0 formulation only!
                pInside = insideVolVars.pressure(1);
                pOutside = outsideVolVars.pressure(1);
            }


Without this modification, I was not able to keep pn constant at Dirichlet 
boundaries. As you see, the modification is hard-coded for the p1s0 formulation.


No, I did not pull any recent dumux versions because I did not want to get 
stuck with compiling of possible incompatibilities 😊 (I work with the version 
from the dumux-course). Can you please point out which files have been modified 
to fix the bug you are mentioning? Or which commit should I be looking for?


Thanks,

Nikolai


________________________________
From: Dumux 
<[email protected]><mailto:[email protected]>
 on behalf of Dennis Gläser 
<[email protected]><mailto:[email protected]>
Sent: Monday, August 20, 2018 10:25:06 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [DuMuX] Linear solver crashes in release mode, but not in debug 
mode


Hi Nikolai,


I am sorry if I missed your previous posts and this question is obsolete, but 
can you tell us what you mean by having corrected darcyslaw.hh? I checked your 
repository but couldn't find a modified version of the file, neither a 
respective branch in the dumux repository. So I assume you have a locally 
modified version of the file on your system?


There used to be a bug in the two-phase model with respect to the p1s0 
formulation. That has been fixed about three weeks ago, have you pulled dumux 
eversince?


Let us know if this helps!


Cheers,
Dennis


On 17.08.2018 19:49, Nikolai Andrianov wrote:

Dear DuMuX experts,


Please advise what can cause the following bizarre error: the code compiled 
with debug options runs smoothly but the same code compiled with release 
options crashes in the linear solver with the following message:


Solve: M deltax^k = rNewton: Caught exception: "SolverAbort 
[apply:/home/nikolai/dumux/dune-istl/dune/istl/solvers.hh:628]: breakdown in 
BiCGSTAB - rho 0 <= EPSILON 1e-80 after 87.5 iterations"


This error pops up when working on a modified version of the exercise-fractures 
test cases from dumux-course. Apart from modifying the -problem.hh and 
-spatialparams.hh files, I have also corrected darcyslaw.hh and switched the 
formulation to p1s0 (as described in my previous post).


Compilation .opts files are attached.


May thanks,

Nikolai




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




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





_______________________________________________
Dumux mailing list
[email protected]<mailto:[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