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: [email protected]
<mailto:[email protected]>
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 <[email protected]
<mailto:[email protected]>> 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: [email protected]
<mailto:[email protected]>
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
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
