`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 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).
In the case where two were direct vertical neighbors in the grid
but not in the underlying cartesian grid (e.g. because of MINPV or
pinch outs), we treated them as NNCs and wrote the transmissibilty
to TRANNC.
With this patch we detect this situation (two neighbor cells with identical
i and i and no active cells between them) and do not create an NNC
in the eclipse output files but write the transmissibility to TRANZ.
It seems like eclipse ignores NNCs with small transmissibility.
Small means less than 1e-6 for Eclipse (Even if it says that it
is ignoring values below 1e-5 and/or zero values)!.
This commit now implements the same threshold during IO.
Also fixes a bug when applying EDITNNC, it needs to have cell1<=cell2 to work.
Previously the vector of NNCData was passed in as a reference and sorted.
Unfortunately, it needed to be transformed later to meet all prerequisites.
With this commit we do this transformations in sortNncAndApplyEditnnc.
Furthermore EDITNNC data is passed by value as it is not needed
outside and should usually not be to big. It was copied outside anyway!
We first add all NNCs specified in the deck to the ouput
and then determine additional NNCs by iterating over all faces that
connect cells that are not connected in the underlying cartesian grid.
Therefore we need to make sure that we do not output NNCs twice
and for faults that also have a specified NNC we need to substract
the transmissibility specified via NNC.
Joakim Hove
Tor Harald Sandve
Andreas Lauser
Atgeirr Flø Rasmussen
Bård Skaflestad
Markus Blatt
Jostein Alvestad
Tor Harald Sandve
Arne Morten Kvarving