If multiple records, from different region sets and region
IDs--e.g., both regions 1/2 in 'M' (MULTNUM) and regions 2/3 in 'F'
(FLUXNUM) applies to the same connection as might be the case in
MULTREGT
1 2 0.5 1* 'NNC' 'F' /
2 3 0.1 1* 'NNC' 'M' /
/
then the total multiplier value is the product of the values from
each record.
This commit revises the region set loop to accumulate the total
multiplier value instead of "just" returning the first match.
This is intended as a possibly temporary measure for processing
explicitly assigned NNCs (keywords NNC/EDITNNC/EDITNNCR) along with
those NNCs arising from numerical aquifers, and for which there is
no associate face direction.
Add a set of unit tests to probe the implementation of all MULTREGT
connection behaviours as exhibited by MULTREGTScanner member
functions getRegionMultiplier() and getRegionMultiplierNNC().
Mostly to group related functions and have the same order in the
declaration and the implementation files. While here, replace an
'enum' with a strong enum since the type does not need to support
arithmetic operations.
This commit passes the run's notion of its active phases, an object
of type Opm::Phases, through to the initialisation layer for the
saturation functions' scaling properties. In particular, this
allows us to discriminate between the phases and to not index into
tables or properties that would not be appropriate (e.g., maximum
gas saturation (SGU) in a simulation run without active gas).
Moreover, we now have enough information to know to look for SOF2 in
two-phase run using family II saturation function keywords. These
changes are necessary in order to extend Flow's support for the
FILLEPS output request to two-phase runs.
motivation: an upcoming parallel frontend to the field props manager.
templated functions cannot be virtualized, and thus having these exposed
would give a great chance of confusing the users in the downstream
code, where properties would be caught from the (potentially) empty
backend instead of from the frontend.
Tune the makefile according to new principles, which adds a few bells
and whistles and for clarity.
Synopsis:
* The dependency on opm-common is completely gone. This is reflected in
travis and appveyor as well. No non-kitware cmake modules are used.
* Directories are flattened, quite a bit - source code is located in the
lib/ directory if it belongs to opm-parser, and external/ if third
party.
* The sibling build feature is implemented through cmake's
export(PACKAGE) rather than implicitly looking through source files.
* Targets explicitly set required public and private include
directories, compile options and definitions, which cmake will handle
and propagate
* opm-parser-config.cmake for downstream users is now provided.
* Dependencies are set up using targets. In the future, when cmake 3.x+
can be used, these should be either targets from newer Find modules,
or interface libraries.
* Fewer system specific assumptions are coded in, instead we assume
cmake or users set up system specific details.
* All module wide configuration and looking up libraries is handled in
the root makefile - all sub directories only set up libraries and
compile options for the module in question.
* Targets are defined and links handled transitively because cmake now
is told about them. ${module_LIBRARIES} variables are gone.
This is largely guided by the principles outlined in
https://rix0r.nl/blog/2015/08/13/cmake-guide/
Most source files are just moved - if they have some content change then
it's nothing more than include fixes or similar in order to make them
compile.
