the idea is to compensate the residual of the final solution of a time
step by means of an opposing source term in the next time step.
This patch has been developed as a joint project with [at]totto82 and
[at]osae.
(`flow` is unaffected by this because for now drift compensation is an
experimental feature and thus disabled within the production
simulator.)
this bitrot a bit because it was never seen by the compiler. (I still
did not check if `ebos` compiles and works if `CpGrid` is replaced by
dune-alugrid or `PolyhedralGrid`.)
the convergence behaviour can now be understood and the report step
information is printed, too. This does not affect `flow`, becase it
implements its own newton and time stepping routines.
Usage
BCRATE
1 1 1 1 1 10 X WATER 1e-7 /
This will inject 1e-7 of water (mass/time/length/length) on the x side of the
boundary cells with cartesian index [1 1 1] to [1 1 10]
this is a compile time switch with the intention to be able to more
easily turn experimental features that are not yet considered to be
production quality on and off. DUNE has a similar mechanism (i.e., the
`DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS` macro), but it relies on
the preprocessor.
For now, the property does not have any effect.
this hopefully makes the purpose of `ebos` clear in its
description. this prose should be interpreted as "if you use ebos in
production, you are on your own and you should only expect a very
limited amount of support (or even sympathy) if something breaks".
in particular the missing synchronization after restarts was very
nasty to find. thanks a ton for pointing this out!
also, IIRC changing DR[SV]DT in the schedule section has been working
properly for a while, so the comment which stated the opposite is
removed as well.
Some time loop stuff was missing in the doobly-doo, the init() method
of the well model was not called and there was the slightly deeper
issue that the initial solutions where not calculated on restarts
which breaks everything that relies on them. (at the moment, that's
everything which is related to non-trivial boundary contitions.)
the purpose of this was a hack to be able to manipulate the Jacobian
matrix directly from outside code. Since `flow` has been converted to
the eWoms wells API, this is not required anymore.
the parameter is called `EclNewtonSumToleranceExponent`. if it is set
to 1, the specified tolerance will be used directly. (this is not
desireable in the general case though, because at the same result
quality, the sum error for large reservoirs can be larger than for
small ones.)
albeit, we scale the error only to the cube root of the pore
volume. the rationale is that the same amount of mass can get lost
"along" a line for each timestep.
maybe it would be a good idea to do something like this for time step
size as well because taking multiple small time steps currently allows
a much larger error in the result than doing it in one big step.
some weird hacks (hello, DR[SV]DT) cause a change of the storage term
in the first Newton-Raphson iteration compared to the solution of the
previous time level. In order to use the correct values, one thus must
explicitly recompute the storage term for the previous time step
instead of just reusing the result of the first Newton-Raphson
iteration of the current time step.
reads tracer input from deck, solves tracer equation fully implicit as a post processing step in endTimeStep
tested on a simple modified SPE1CASE1 deck and compared with eclipse
TODO: restart and parallel
this is similar to the mechanism for well models: the API is defined
here, but can be overloaded by downstream modules. In contrast to the
well model where the default class follows a simplistic approach the
default class for aquifiers does nothing, i.e., the actual
implemenentation must be provided by downstream.
