the reason is to make sure for blackoil cases, the same algorithm will
be used to invert the D matrix for the well model. As a result, it will
reduce the burden to test the PR.
Whether we will keep this algorithm for 4 X 4 matrix will be addressed
as a separate issue.
`mebos` works similarly as `flow`, but in contrast to `flow`, `mebos`
only creates the deck in the common code path whilst the
'EclipseState' and the other higher-level parser objects are always
created internally by the vanguard. this approach avoids code
duplication and the worst effects of parser API creep.
to avoid having to compile non-trivial compile units multiple times,
the actual code of the variants is moved into `ebos_$VARIANT.{hh,cc}`
files and the respective compile units are each put into a small
static library whilst the main function of said libraries are invoked
by either the multiplexed or the respective specialized simulator's
`main()`. This is also somewhat similar of how `flow` works, with the
difference that `mebos` uses the blackoil variant to determine the
parameters it needs to know for parsing the deck instead of
introducing a "fake" type tag for this. The rationale is to reduce
compile time compared to the "fake type tag" approach and -- to a
lesser extend -- avoid unnecessary copy-and-pasting of code. In
particular, this means that for the vast majority of cases, only one
place needs changed in the code for all `ebos` variants if, for
example, the parser API requires further objects in the future.
This replaces the makePreconditoner() function. The main advantage
is that it is extensible, making it easy to for example add new
preconditioners to the factory at runtime. It supports both parallel
and serial preconditioners.
Also use it in flow_blackoil_dunecpr.cpp. Adds new command-line parameter,
--linear-solver-configuration-json-file, to read linear solver config from
JSON-format file at runtime.
this makes slightly incorrect decks usable with `ebos`. since the
common `flow` variants use a different code path to parse the deck,
they are unaffected. (as far as I can see, the only variant which
might be affected is `flow_ebos_oilwater_polymer_injectivity` and even
for it `flow`'s multiplexing code will abort the run before the
vanguard is even called.)
The intend is to make the purpose of `ebos` clearer: while it can be
used in production, the stability guarantees are somewhat lower than
for `flow` and testing is a bit less rigorous (most of the time).
