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.
the speedup gained by parallelism here are simply not worth the
headaches.
note that `flow` is unaffected by this because it uses
`Opm::BlackoilWellModel`.
the original purpose of those is to provide a checkpoint/restart
mechanism using an ad-hoc file format. They might also be useful for
implementing the adjoint functionality, though.
using the eWoms API for wells, the Schur compliment was not applied at
all. If `BlackOilWellModel::linearize()` was made non-trivial, the
Schur complement was applied twice in `flow`. With this patch, we only
apply this using the eWoms API (in
`BlackOilWellModel::linearize()`). I could not observe a signficant
effect on the convergence behaviour of `flow` for the cases which I
tested (Norne and realization 5 of Model 2).
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.
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.
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.
the flags which I used are
```
-pedantic \
-Wall \
-Wextra \
-Wformat-nonliteral \
-Wcast-align
-Wpointer-arith \
-Wmissing-declarations \
-Wcast-qual \
-Wshadow
-Wwrite-strings \
-Wchar-subscripts \
-Wredundant-decls \
-fstrict-overflow \
-O3 \
-march=native \
-DNDEBUG=1
```
note that some heavy filtering is not the worst idea because DUNE is
far from not emiting any warnings with these flags.
Also, there were some pesky warnings in test_ecl_output which I don't
know how to fix:
```
tests/test_ecl_output.cc:218:73: warning: missing initializer for member ‘Opm::data::Connection::effective_Kh’ [-Wmissing-field-initializers]
```
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.
the way to get the result of an evaluation is by return value, i.e.,
z = fn.eval(x, y);
not by passing a separate argument to the eval() function like
fn.eval(x, y, z);
the `XYTabulated2DFunction` used the latter approach causing an API
inconsistency with all other tabulation classes in
opm-material. OPM/opm-material#319 fixes that but requires this mop-up
as a consequence.
IMO the simulator should not be in the business of managing low-level
parser objects in the first place, because that's what EclipseState is
supposed to do?!
anyway, since these objects are not needed to decide which simulator
to use, they are now always managed internally by the vanguard, i.e.,
setExternalDeck() does not take them anymore.
it is possible that a dune entity vanishes if its iterator gets out of
scope. Whether this is a problem or not seems to be be highly depend
on the used configuration...
also, clean them up a bit:
- do not use the intensive quantities cache directly anymore. (i.e.,
that code should now work if the IQ cache is disabled)
- do not fiddle with the global Jacobian matrix and residual vector
directly. Instead, implement the water fluxes to the reservoir as a
source term like wells.
one thing that did not become fully clear to me is if each aquifer
ought to be assumed to be in contact with the whole reservoir or just
a few cells on the boundary. The current implementation goes down the
former path, while, without any deeper knowledge, I would rather
suppose that the latter applies. maybe my understanding of this is
just too limited, though.
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.
also, add a "reading deck" output. The idea is to make `flow`'s
behaviour less surprising by preventing people from thinking that
nothing happens after starting `flow` for a large deck.
so far, the actual specializations of the simulator were compiled into
the `libopmsimulators` library and the build of the glue code
(`flow.cpp`) thus needed to be deferred until the library was fully
built. Since the compilation of the glue code requires a full property
hierarchy for handling command line parameters, this arrangement
significantly increases the build time for systems with a sufficient
number of parallel build processes. ("sufficient" here means 8 or more
threads, i.e., a quadcore system with hyperthreading is sufficient
provided that it has enough main memory.)
the new approach is not to include these objects in
`libopmsimulators`, but to directly deal with them in the `flow`
binary. this allows all of them and the glue code to be compiled in
parallel.
compilation time on my machine before this change:
```
> touch ../opm/autodiff/BlackoilModelEbos.hpp; time make -j32 flow 2> /dev/null
Scanning dependencies of target opmsimulators
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_gasoil.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_oilwater.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_blackoil.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_solvent.cpp.o
[ 4%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_polymer.cpp.o
[ 6%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_energy.cpp.o
[ 6%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_oilwater_polymer.cpp.o
[ 6%] Linking CXX static library lib/libopmsimulators.a
[ 97%] Built target opmsimulators
Scanning dependencies of target flow
[100%] Building CXX object CMakeFiles/flow.dir/examples/flow.cpp.o
[100%] Linking CXX executable bin/flow
[100%] Built target flow
real 1m45.692s
user 8m47.195s
sys 0m11.533s
```
after:
```
> touch ../opm/autodiff/BlackoilModelEbos.hpp; time make -j32 flow 2> /dev/null
[ 91%] Built target opmsimulators
Scanning dependencies of target flow
[ 93%] Building CXX object CMakeFiles/flow.dir/flow/flow.cpp.o
[ 95%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_gasoil.cpp.o
[ 97%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_oilwater_polymer.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_polymer.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_oilwater.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_solvent.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_blackoil.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_energy.cpp.o
[100%] Linking CXX executable bin/flow
[100%] Built target flow
real 1m21.597s
user 8m49.476s
sys 0m10.973s
```
(this corresponds to a ~20% reduction of the time spend on waiting for
the compiler.)
i.e., mine (openSuse Tumbleweed). the problem seems to be that the
specialization of `ISTLSolver::constructAMGPrecond()` is ambiguous and
some compilers seem to be more strict about this than others. Simply
removing the problematic method seems to work fine.
That said, for non-legacy `flow` this codepath is not taken at runtime
anyway because the `ISTLSolverEbos` class is used!?
before this patch, the parameter was registered by the problem but not
used there. Since this is quite confusing, let's move registration to
where the parameter is actually used, i.e., the vanguard.
i.e., complain when detecting foo=bar positional parameters. this is
not a bullet-proof solution because it will not work if the deck file
name contains an equals character. Anyway, it's better than before
IMO.
- Change the brief description slightly
- Do not print anything anymore if there are no unused parameters
- Change the boiler plate text for printing the parameters to the
PRT/DBG files
in part, this has been requested by [at]atgeirr.
bph should be "bhp" and "DWellFractionMax" looks weird as a command
line parameter (-d-well-fraction-max). now, it only looks slightly
weird in the c++ code.
this has been requested by [at]atgeirr.
Note: The FlowLinearSolverVerbosity, FlowNewtonMaxIterations and
FlowNewtonMinIterations parameters are still prefixed because they
clashes with parameters registered deeply within eWoms.
while they do no longer appear in the help message, in the code they
are still there and can be specified and used as normal.
also, this patch makes --print-parameters=1 and --print-properties=1
work.
this has several advanges:
- a consistent and complete help message is now printed by passing the
-h or --help command line parameters. most notably this allows to
generically implement tab completion of parameters for bash
- the full list of runtime parameters can now be printed before the simulator
has been run.
- all runtime parameters understood by ebos can be specified
- no hacks to marry the two parameter systems anymore
- command parameters now follow the standard unix convention, i.e.,
`--param-name=value` instead of `param_name=value`
on the negative side, some parameters have been renamed and the syntax
has changed so calls to `flow` that specify parameters must adapted.
Andreas Lauser