Timo,
I am reviving this old thread about a bug that you fixed ten months ago.
It seems that the fix was not merged into the 3.3 release nor in the
current master branch. Why is that? Is it because of a performance
degradation that it can bring? Or absence of a test case?
Will it be possible to have this fix in DuMux release at least as an
option (which you already provided under the name of
BoxVolVarsDependOnOneDofOnly, false by default)? Setting it to true by
default will keep things as they are for users who do not have the
pressure gradient affecting relative permeability.
Best regards,
Dmitry
On 02.06.2020 20:09, Dmitry Pavlov wrote:
Timo,
I have been checking with my management about what I can do.
Unfortunately, I can not share neither the code nor the data of our
program for which the fix is relevant. Yes, DuMux is GPL-ed, but we
are developing code for a customer, and it will be strictly up to the
customer whether to share the code further (under GPL) or not. The
data (relative permeability functions etc.) is believed to be a
commercially sensitive information.
I could, in principle, work on some special reduced shareable version,
but, unfortunately, I have many other things on my tab that have high
priority at the moment.
One thing that is easily shareable is the reference to description of
the underlying surfactant model. It was developed elsewhere, see PhD
thesis [1], or [2] for much shorter version.
Another piece of information that may be important for the convergence
are the boundary conditions.
Left boundary: constant influx of water solution with a constant
concentration of the surfactant.
Right boundary: constant pressure, also ds/dn = 0 (so pressure
gradients of wetting and nonwetting phases coincide).
Without the fix, there is a convergence, but the step falls down to
seconds, so that is much slower overall than with the fixed version.
Best regards,
Dmitry
[1] https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/240038
[2]
https://www.sintef.no/contentassets/0d97862cef164d1c965d268ce5e4e082/surfactant_model.pdf
On 28.05.2020 19:07, Timo Koch wrote:
Hi Dmitry,
glad to hear! We have been discussing the issue in the last developer
meeting.
The fix introduces a significant overhead in the assembly but is not
necessary for most simulations.
Also, without the fix although the Jacobian is just an approximation,
the Newton might still converge (maybe with lower rate) but the
overall runtime might still be faster.
We didn’t have a simulation so far—as your case— where the Newton
fails completely which is why no-one noticed the bug so far.
It would be very helpful for us if you would consider contributing a
test-case (maybe a simplified version of your setup) which fails
without the fix and passes with it.
Otherwise we’d have to construct something to test for this bug,
which might end up being only a rather academic example.
So in case you can find the time to help us out there it would be
most appreciated.
Best wishes
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 28. May 2020, at 17:56, Dmitry Pavlov <dmitry.pav...@outlook.com
<mailto:dmitry.pav...@outlook.com>> wrote:
Timo,
That fix also solved the convergence problem with surfactant
simulation from which my program has been suffering, so it was very
important fix and I thank you again for it.
Best regards,
Dmitry
On 27.05.2020 17:49, Dmitry Pavlov wrote:
Timo,
Thank you! I cherry-picked the commit into my DuMux installation
and now my numerical derivative matches the analytical one.
Best regards,
Dmitry
On 27.05.2020 15:08, Timo Koch wrote:
Hi Dmitry,
to follow up on your bug report, I opened an issue
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/892.
There is a simple fix here:
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2146
Can you try if this improves your convergences / fixes your problem?
The problem with this solution is that it significantly increases
the runtime for models where it is known that there is no dependence
of the scv volume variables on the other dofs of the same element.
It might be possible to deduce this somehow.
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 26. May 2020, at 17:13, Dmitry Pavlov
<dmitry.pav...@outlook.com <mailto:dmitry.pav...@outlook.com>> wrote:
Hello,
I am trying to do a 1D porous medium flow simulation where one of
the components is a surfactant that affects krw and krn. The
effect of the surfactant depend on pressure gradient.
Earlier, an attempt [1] was made to apply CC method for this kind
of problem. It turned out that DuMux API does not easily allow to
estimate a gradient in TPFA, and, following Timo Koch's advice, I
gave a try to Box method.
I think I am having some trouble with derivatives now. Looking at
this comment in boxlocalassembler.hh, I am beginning to
understand why.
// Calculate derivatives of all dofs in stencil with
respect to the dofs in the element. In the //
// neighboring elements we do so by computing the
derivatives of the fluxes which depend on the //
// actual element. In the actual element we evaluate the
derivative of the entire residual. //
Why the trouble? Well, I am calculating the pressure gradient (by
calling evalGradients) inside this method
MaterialLawParams materialLawParams(const Element& element,
const SubControlVolume& scv,
const ElementSolution& elemSol) const
Here, I store the needed numbers for krw and krn calculation in
MaterialLawParams, and they are properly downstream at
MaterialLaw::krw and MaterialLaw::krn.
Now, let my have two neighbor boxes, 0 and 1. Pressure in box 1
affects the krw/krn in box 1. evalGradients, when called, duly
calculates pressure gradient in box 0 depending, among others, on
the pressure value in box 1. That is good.
But it turns out that the numerical differentiation algorithm
does not bother to call materialLawParams() for scv-s in box 0
when it calculates the derivatives of fluxes in box 0 w.r.t.
pressure in box 1. I suppose that it has to do with the comment
above. I suppose that it takes into account only the
"transmissibility" part of the effect of pressure in box 1 to
flux in box 0, and skips the part that comes from krw/krn
sensitivity to the pressure gradient.
Also this comment in boxlocalassembler.hh may be relevant too.
// TODO additional dof dependencies
I will very much appreciate answers to the following questions:
1. Am I correct about the behavior of the numerical Jacobian
assembler, or it should be all right and there is a bug somewhere
in my code or DuMux's?
2. In case I am correct, is there an easy (or not) way to force
DuMux into recalculating the material law parameters for scv-s
that belong to DOFs w.r.t. which we take the derivative? Or take
some other approach?
3. If not, will the hand-made analytic Jacobian help? Or it will
fail due to some other assumption in the DuMux engine that is not
true for my problem?
(I actually have the analytic Jacobian implemented, but not quite
sure it is correct, partially because, well, I never had a chance
to test it against a correct numeric Jacobian).
Thank you for your time.
Best regards,
Dmitry
_______________________________________________
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
