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.
Somehow some standard output when running MILU () is still there and
it really clutters the output and and makes it unusable. This commit
removes it from flow.
I tested #1712 without deriving the `EclFlowProblem` type tag from
`FlowIstlSolver`, and it worked because the linear solver was still
`Opm::ISTLSolverEbos` because the linear solver is set via the
`LinearSolverSplice` a few lines down.
This time, I verified that the
`Ewoms::Linear::ParallelBiCGStabSolverBackend` was used if the
offending line was commented out. also, Norne worked fine with the
default solver as long as the Schur complement for the wells was done
explicitly.
Finally, the naming of the eWoms API is a bit inconsistent
(`setMatrix()` vs. `setResidual()`). any opinions here? I'm fine with
whatever.
