> On 11. Nov 2020, at 18:26, Dmitry Pavlov <[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 <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]> 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
