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
