this simply excludes the disabled simulators from `make all` while
`make flow` will continue to work even if the cmake variable
`BUILD_FLOW` was set to `OFF`. This requires a small patch for
opm-common.
these variants should cover most of the common use cases. That said,
there are no plans to provide simulators for combinations of blackoil
extensions or a "multiplexing" simulator like `flow`: If someone is
interested in e.g., an oil-water simulator with polymer and energy
enabled, a separate self-compiled executable should be added locally.
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.)
for some reason, libraries produced for a module are not linked to the
executables of the module by the default build system. so far this did
not matter for `ebos` but with this PR, it starts using stuff from
`libopmsimulators`...
This enables `ebos` to run Norne and other non-trivial data
sets. While at it, adapt the tolerances by `ebos`.
This patch only affects the research simulator, i.e. `flow` is
unaffected by it.
these parameters where introduced with support for the TUNIING keyword
in `ebos`. since `flow` implements its own time stepping these
parameters are unused and should thus be hidden from view in it.
the former is caught by `ebos`, while the latter isn't. Alternatively,
this can be fixed by deriving `LinearSolverProblem` from
`NumericalIssue`, if preferred.
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.
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).
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]
