the vanilla setup-tools doesn't get the triplet correctly for some
reason. also use cmake from pip as cmake 3.16 in the image has a bug
in the python find rule
this went unnoticed since there are no UDQDefines in the pre-simulation
Schedule broadcast for parallel. however it causes issues for serialized
restarts
This commit adds a special case for handling the dynamic nature of
the number of records in the ROCK keyword. In particular, if the
ROCKOPTS keyword is NOT entered before ROCK, then the number of
records is NTPVT--item 2 from TABDIMS. Conversely, when ROCKOPTS is
entered before ROCK, the number of records in the latter depends on
the setting in item 3 of ROCKOPTS.
This interaction cannot be easily captured in our JSON-based models,
so we introduce a special size class, SPECIAL_CASE_ROCK, that only
applies to the ROCK keyword and implement the logic in a dedicated
function in 'Parser.cpp'. Once we have determined the correct
number of records, we form a RawKeyword of type FIXED and defer
further processing to the existing handling of fixed-sized keywords.
Add a selection of unit tests to exercise the new behaviour.
Switch if/else chain out in favour of a map-based approach. This
simplifies adding new enumerators. While here, also return string
objects instead of constant string objects.
It is needed as we will call pybind11_add_module which calls
python3_add_library (in recent pybind11 versions). That
function is only there if the development component is searched for
and found.
std::unique will keep the first occurrence and std::sort will keep
the order of equal elements. Hence we use a deque with the EDITNNCR
entries in reverse order (last one specified comes first). The we sort
this and make unique it unique.
If there is an EDITNNCR entry and a NNC entry for the same cell pair
then the EDITNNCR entry is not be represented inernally but we simply
overwrite the transmissibility of the corresponding NNC entry.
If there is an EDITNNC entry and an EDITNNCR entry for the same cell
pair then the EDITNNC entry is removed while internalizing EDITNNCR.
Order matters for EDITNNCR entries in the sense that later specified
values will overwrite previous entries when we internalize.
Note that similar to EDITNNC only the first 7 options are represented
and the rest is ignored by OPM flow.
Note that EDITNNCR entries for neighboring cells are ignored (like for
EDITNNC).
