Some SCHEDULE keywords can set a well to be OPEN to open a reviouly STOP or SHUT well.
The well is SHUT/STOP due to various causes (SCHEDULE, economical, physical, etc.)
For now, the WELOPEN, WCONPROD and WCONINJE keywords are considered with this event.
In the future, other keywords can be involved if found to have the
similar OPENing functionality.
This commit extracts the internal helpers of class
InterRegFlowMap
out to a new public helper class template, CSRGraphFromCoordinates.
Client code can, at the expense of one additional data member and
some dynamic memory, elect to track the index pairs. This enables
O(1) assembly per element when used as part of a CSR matrix with a
value array, SA.
Class CSRGraphFromCoordinates does not track values. It is purely
for the sake of forming the IA and JA structure arrays. Upon
calling 'compress()', column indices are sorted per row and
duplicate column indices condensed to a single, unique,
representative.
Fixes
```
/opm/input/eclipse/Schedule/Schedule.hpp:241:14: error: ‘function’ in namespace ‘std’ does not name a template type
241 | std::function<std::unique_ptr<SegmentMatcher>()> segmentMatcherFactory(std::size_t report_step) const;
| ^~~~~~~~
```
The existing implementation used the UDQ State object to track
pending ASSIGN operations, mainly in terms of the report step index,
but this implies that the logic implicitly assumes an ASSIGN
operation can run at most once per report step. That assumption
usually holds, but fails if the ASSIGN operation is triggered from
an ACTIONX block that happens to run multiple times within a report
step.
This commit instead introduces a new data member,
UDQConfig::pending_assignments_
that keeps track of all ASSIGN operations that have been added for
the current report step. We clear those pending assignments when
forming a new Schedule block (ScheduleState object), under the
assumption that all pending ASSIGN operations have been affected at
the previous time level (report step).
In effect, this new data member assumes the role of
UDQState::assignments
and we therefore remove that data member and update the signature of
UDQState::add_assign()
to account for the fact that the 'report_step' parameter is no
longer needed.
This commit adds parser and evaluation logic necessary to handle
ASSIGN statements for segment level UDQs. This requires a segment
matching facility in UDQConfig::add_assign() which, in turn, must be
passed from the calling context in Schedule::handleUDQ(). Update
APIs accordingly.
We also split handling segment level UDQ assignments to a new helper
function, UDQConfig::add_enumerated_assign(), which might be
generalised to handle block level UDQs in the future.
This commit adds logic that enables recognizing segment level UDQs
in the summary output writer. We calculate all segment level UDQs
and add the values to the summary state for possible use in ACTIONX
too. The latter is not yet tested.
This commit adds support for calculating UDQs at the segment level,
i.e., UDQs named 'SU*'. This necessitates an API change for the UDQ
context constructor and, transitively, every function that forms UDQ
context objects. We pass a factory function that will create
segment matcher objects on demand, and provide a default
implementation of this factory function in the Schedule class.
The existing algorithm was a little too fragile and dependent on
branch numbers. This new version starts at segment 1/branch 1 and
follows Segment::inletSegments() in depth-first order, taking care
to enqueue new branches as they're encountered instead of in
numerical order. We search to the end of each branch before
switching to the next branch. This ensures determinism regardless
of branch numbering and input ordering.
While here, switch iLBR_ to a WindowedMatrix<int> to simplify branch
references in the output table.
This is in preparation of revising the algorithm for ILBR/ILBS.
Mostly splitting long lines, adding missing headers, passing scalars
by value, and making three helper structures private to the
implementation file. There are no external users of these types.
This commit switches the region set tag matching algorithm to using
unique prefixes. This enables the parser to recognise that the
summary vector
ROPR_UNI
should match up with the user defined region set 'FIPUNIT'. In the
current master sources, the above summary vector would produce a
diagnostic message saying that the region set 'FIPUNI' (without the
final 'T') does not exist.
We add a prefix-to-canonical region set name translation table to
the FieldProps class and funnel all FIP-like requests through this
translation table. In the case of non-unique prefixes-e.g., FIPUNIT
and FIPUNIX, we currently elect to have the last keyword entered in
the simulation model "win". This behaviour may be altered in the
future if deemed appropriate/necessary.
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().
- Enables use with THERMAL. Note that enthalpy of H2 dissolution process is not included due to lack of published data on this (as far as I have seen).
- Enables use with DIFFCGAS and DIFFCWAT.
- Enables use with dynamic brine module.
- New H2 table made with Coolprop which includes enthalpy data.
Region level summary keywords may have suffixes which refer to user
defined region sets ('FIP*' keyword). This commit prunes those
suffixes when performing function lookup, so that we do not get
false negatives.
To this end, introduce a new helper function
EclIO::SummaryNode::normalise_region_keyword()
and use this both when determining the summary keyword type (rate,
cumulative, pressure &c) and when looking up evaluation functions
for region level summary vectors. The new helper could arguably
have been integrated into the existing 'normalise_keyword()' helper
function, but that would have necessitated a different change
elsewhere in the code base. For now, we keep this helper as a
separate function.
This commit implements the 'NOAQUNNC' behaviour in member function
MULTREGTScanner::getRegionMultiplier()
We use the new 'aquifer_cells' data member to identify connections
to and within numerical aquifers and ignore those if the record
stipulates 'NOAQUNNC' behaviour.
This commit adds a new data member
MULTREGTScanner::aquifer_cells
which holds a sorted sequence of Cartesian/global cell indices
corresponding to the cells which comprise the model's numerical
aquifers. These are needed to properly identify whether or not a
connection--i.e., a cell pair--would constitute a "numerical aquifer
connection" and be subject to 'NOAQUNNC' treatment.
We assign the numerical aquifer cells as part of member function
EclipseState::conveyNumericalAquiferEffects
which runs at EclipseState construction time. We know all numerical
aquifers at that point.
This is mostly to have a general solution for matching region level
summary keywords which may reference a user-defined region set (FIP
keyword, e.g., FIPXYZ) through tags like
RPR__XYZ -- Average pressure in region, FIPXYZ region set
ROPR_XYZ -- Oil production rate in region, FIPXYZ region set
RODENXYZ -- Average oil density in region, FIPXYZ region set
The initial approach introduced in commit cfbafc236 was limited to
selected keywords.
To this end, add a new data member
std::string ParserKeyword::m_matchRegexSuffix
and introduce a new member function
bool ParserKeyword::matchesDeckNames()
which matches a candidate keyword string against the m_deckNames,
and, if applicable, as a regular expression against m_deckNames when
appended m_matchRegexSuffix.
The MULTREGT keyword has an independent way of defining the default
region--the default value of item 6--and does not need the default
GRIDOPTS-base region protocol of the other *REG keywords.
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 adds a new, focused, member function
NumericalAquifers::allAquiferCellIds()
which returns a vector of those Cartesian/global cells that have
been marked as defining the model's numerical aquifers through the
AQUNUM keyword. We intend to use this to identify those NNCs that
go to numerical aquifers--or between numerical aquifer cells--as
those may need special treatment when processing the MULTREGT
keyword.
The 'base' checks that the input string looks like a valid keyword
and, if so, matches the string against the builtin set of known
keywords. The full keyword recognition process additionally
includes those keywords that match against keyword collections,
typically the SUMMARY section "meta" keywords in the *_PROBE files.
We will use the 'base' recognition separately to introduce support
for extension keywords with long--more than eight character--names.
This commit replaces the data members 'nx', 'ny', and 'nz' with a
copy of the GridDims object passed as an argument to the
constructor. In turn, this enables using GridDims::getIJK() to
compute the cell's IJK tuple from its global Cartesian index instead
of implementing the same calculation locally (and incorrectly).
While here, also include the layer index (K) in determining whether
or not a connection is an NNC, and do this just once instead of once
for each MULTREGT record. Cells (I,J,K) and (I,J,K+3) might be
connected across pinched-out layers and for the purposes of MULTREGT
that connection should be treated as an NNC.
In particular, ensure that we include all requisite headers, hide
type aliases that are not needed outside the class, consistently use
std::size_t, split a few long lines, and switch to range-for in one
location.
A numeric index serves the same purpose as a pointer in this very
specific instance and also has the benefit of being easily
transferable between processes. This, in turn, means we can remove
the 'getSearchMap()' and 'constructSearchMap()' member functions.
These are not directionally dependent, and they have a unit string
of 'Pressure'. This didn't use to matter, but upcoming changes
will depend on the unit string being correct.
