Hi Dmitry,
it would be nice if you could share with us what you had to change to make things work with Float128. Ideally, you would fork the corresponding repository and create one or several merge requests like described here: https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html With "seems to work", do you mean that the irregularities vanish? I would suppose no, since you will still have small numerical deviations triggering the behavior. If you want to quantify the influence of physical parameters on the fingers, you have to apply measures that don't depend on the numerical setting like grid size or solver thresholds. Which is probably something like onset time, finger length and things like that, but I'm certainly no expert here. Kind regards Bernd -- _________________________________________________________________ Bernd Flemisch IWS, Universität Stuttgart phone: +49 711 685 69162 Pfaffenwaldring 61 email: [email protected] D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/> _________________________________________________________________ ________________________________ Von: DuMux <[email protected]> im Auftrag von Dmitry Pavlov <[email protected]> Gesendet: Sonntag, 15. November 2020 13:21:23 An: Timo Koch Cc: DuMuX User Forum Betreff: Re: [DuMux] 1p and symmetry Timo, Thank you. 128-bit arithmetics seems to work, after I have made two obvious type conversion fixes in dumux and one in dune-istl. Is it supposed to work with UMFPack, too? (It is not clear to me because UMFPack is external and may not care about what my Scalar type is.) As of now, I have not made up my mind about which fingers are physical and which are not. I merely study the effect that different settings, like variation of permeability, viscosity law etc. have on fingers. It seems to be a complicated subject to me because there is a mix of factors, and because simulations, math, and real world are but loosely connected in regards to fingers. I wanted to get rid of at least one of the finger-affecting things, that is, numerical errors. Best regards, Dmitry On 11.11.2020 20:37, Timo Koch wrote: On 11. Nov 2020, at 18:26, Dmitry Pavlov <[email protected]<mailto:[email protected]>> wrote: Timo, Thank you for the quick answer. It is incompressible two-component flow, with viscosity dependent in a nonlinear fashion on the concentration of a polymer in water. The irregularities start out very small, about 1e-13 relative to the values, but soon after they appear, they grow into large structures (viscous fingers). That is the nature of the problem being solved: a small irregularity grows into a big one very fast. I am not having a problem with numerical errors per se -- it is the irregularity of those errors over y that causes the problem. Numerical errors over x are not a problem. Mmh, what makes you think that the result is not physical? Viscous fingers will usually swirl no, and be of different length and so on? Tiny numerical errors will act as seeds for the fingers. This will probably also depend a lot on grid resolution. I will play with Assembly.NumericDifference.BaseEpsilon to see if that helps, but I do not put much hope on it because, again, as inexact as the Jacobian entries may be, they are equally inexact over y, as long as the flow is 1d. I did not know that DuMuX can do quadruple precision. How do I enable it? You set the scalar type to Dune::Float128 (see https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/implicit/incompressible/problem.hh). As far as I can see it’s only tested for a 1p problem now so you might run into problems but basically all operations that work for double are also implemented for Dune::Float128. Timo Best regards, Dmitry On 11.11.2020 20:16, Timo Koch wrote: On 11. Nov 2020, at 17:32, Dmitry Pavlov <[email protected]<mailto:[email protected]>> wrote: Hello, I am running a fairly simple 1p porous flow simulation which is on a 2D rectangular grid. In a particular case I came at, the initial and boundary conditions, as well as spatial parameters, do not depend on the "y" coordinate, only on "x". There is no gravity and the flow is designed to be strictly horizontal. So I naturally expect the results to be essentially 1-dimensional, i. e. the solution at any moment in time should be a function of x and not of (x,y). But after some time, I get irregularities over the "y" axis, that I think come from the linear solver. They are small, but they cause further inconsistencies. Hi Dmitry, we’ll probably need some more information to be able to help. What are you simulating exactly? A compressible flow problem? Seems to be non-linear since you use a Newton solver I guess? In case you are solving some kind of problem with density differences, there could be also physical instabilities but I assume you ruled that out by your setup. What do you mean by irregularities along y? Are they significant? Much more than numerical precision? What’s the magnitude of pressure in your problem and what are the differences in the y-axis? I tried AMGBiCGSTABBackend, ILU0BiCGSTABBackend and UMFPackBackend and the problem persists. I tried to play with the convergence criteria (LinearSolver.ResidualReduction, Newton.MaxAbsoluteResidual, Newton.ResidualReduction, Newton.MaxRelativeShift). Some of them helped to mitigate the problem, but did not eliminate it. Strictening the criteria too much kills the convergence. UMFPack is a direct solver, so this is as much accuracy as you get I guess. You can try adjusting the Epsilon of the numerical derivatives (Assembly.NumericDifference.BaseEpsilon, see https://dumux.org/docs/doxygen/master/a00005.html). If you are fancy you can also switch from double to quad precision floats and see if this reduces the error. Are there any options that I can set for solvers to force them to respect the symmetry of the problem over one axis? No. You would have to write your own solver. Timo (I know that I can use a 1D grid and have a consistent solution, but that will not help in 2D situations where I have part of the system depending on (x,y) and the other part depending only on x.) Best regards, Dmitry
_______________________________________________ DuMux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
