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 D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ _________________________________________________ > On 28. May 2020, at 17:56, Dmitry Pavlov <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 >>> <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 >>> >>> <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 >>>> >>>> >>>> >>>> [1] https://listserv.uni-stuttgart.de/pipermail/dumux/2020q2/002516.html >>>> <https://listserv.uni-stuttgart.de/pipermail/dumux/2020q2/002516.html> >>>> >>>> _______________________________________________ >>>> 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
