This commit adds support for recognizing a small subset of the
summary quantities that are reported at the node level of an
extended network--especially the 'GPR' keyword.
Briefly, we add a new 'Node' config category and a processor for
this category which knows about the distinction between nodes and
groups. It uses member function ExtNetwork::node_names() to produce
configuration nodes whose named entity is the node rather than a
group. Deriving this list of node names across all timesteps is
potentially expensive, so perform this operation at most once and
pass the result into the processor from the SummaryConfig
constructor.
Add a simple unit test for demonstration purposes.
This commit adds a new member function
ExtNetwork::node_names() const
which collects the names (std::string) of all nodes in a network.
The immediate use case is creating summary config nodes for network
level quantities specified without explicit lists of nodes, e.g.,
GPR
/
Add a simple unit test for demonstration.
Previously modifications were applied directly to the field
properties. Unfortunately, for unset TRANX this resulted in
modifying 1.0 even if the simulator is calculating
transmissibilities itself. This was one of the reasons
why we got wrong results (others are in the simulator code).
Now these operations recorded in a calculator which can later be
applied to compressed arrays using apply_tran.
This commit introduces a new helper structure, RawFunctionValues,
which collects unscaled saturation function values that are needed
for vertical scaling of saturation functions using keywords such as
KRO, KRORG, KRGR, PCW
and their hysteretic and directional counterparts. We also
introduce a new helper function, getRawFunctionValues, which
extracts those values from the function tables in TableManager.
Add a set of unit tests to exercise the new feature.
In particular, fix a few instances of "signed vs. unsigned"
comparisons, one "no previous declaration for", and include the
<algorithm> header for std::find().
A quite typical situation is that a UDQ keyword is first initialized with UDQ
ASSIGN statement, and then subsequently a formula for updates every timestep is
entered with UDQ DEFINE:
UDQ
ASSIGN FU_VAR1 0 /
DEFINE FU_VAR1 FU_VAR1 + 1 /
/
Then the assign statement should be run once, and the define formula should be
evaluated for every subsequent timestep.
