add mebos, a multiplexed ebos variant

`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 commit is contained in:
Andreas Lauser
2019-06-11 10:22:11 +02:00
parent 47f4e750d2
commit ca8ea76818
29 changed files with 1063 additions and 91 deletions

View File

@@ -40,7 +40,8 @@ void flowEbosBlackoilSetDeck(double setupTime, Deck &deck, EclipseState& eclStat
typedef GET_PROP_TYPE(TypeTag, Vanguard) Vanguard;
Vanguard::setExternalSetupTime(setupTime);
Vanguard::setExternalDeck(&deck, &eclState);
Vanguard::setExternalDeck(&deck);
Vanguard::setExternalEclState(&eclState);
Vanguard::setExternalSchedule(&schedule);
Vanguard::setExternalSummaryConfig(&summaryConfig);
}