This commit, a preparation for restoring cumulative quantities from
a restart file, reinitialises Summary::prev_time_elapsed in the case
of simulation restart and adds a check to
Summary::write_timestep()
which throws if the input argument 'secs_elapsed' is prior to the
previously recorded elapsed time. The latter is a change in the
behaviour of write_timestep(), but ensures that we don't integrate
rate quantities across a very large timestep in the case of
simulation restart and also prevents double accumulation.
Update impacted unit tests accordingly, and move FIRST_SIM's START
date into the RUNSPEC section where it belongs.
This commit introduces a new predicate,
bool SimulationConfig::isThermal() const
that determines whether or not either of the keywords
TEMP or THERMAL
are specified in the RUNSPEC section of a simulation run.
We only support a small subset of segment-related summary vectors
and must avoid being tricked by other SUMMARY section keywords that
happen to begin with a character 'S' (e.g., SUMMARY itself or the
SUMTHIN keyword). Add an explicit white-list of the vectors we do
support and bypass all others in helper function 'keywordS()'.
Introduce a dummy 'SUMTHIN' specification to SOFR_TEST.DATA to
ensure that we don't accidentally match this in 'keywordS()'.
This commit extends the logic of determining which wells to consider
as multi-segmented to scanning all declared report steps. We also
use a similar protocol to determine the maximum number of segments
for an MS well across all declared report steps.
Segment flow rates and pressures retrieved from a SummaryState
object do not need additional processing steps. The SummaryState
protocol guarantees that the quantities are already stored according
to their proper output unit conventions and abide by the flow rate
sign requirements of the summary/restart files (production
flows--from reservoir to well--treated as positive).
Remove the pertinent processing from RSeg::staticContrib().
This commit completes the set of unit tests for the segment-related
summary vectors
SOFR, SGFR, SWFR, and SPR
by adding a test (Restart_Segment/Write_Read) that serializes the
result of multiple Summary::add_timestep() calls for SOFR_TEST.DATA
and reads that summary file back in.
This commit makes the helper function find_wells() aware of summary
vectors defined on segments. Previously, this helper function would
return an empty list of wells in the case of ECL_SMSPEC_SEGMENT_VAR
whence all segment-related summary vectors would be zero at all
times.
Add a small set of unit tests to verify that we transmit the known
(small) set of segment-related summary vectors (SOFR, SGFR, SWFR,
SPR) to the internal "prev_state" with correct output units and sign
convention (producing flow rates--reservoir to well--positive).
This commit extends the processing of segment-related summary
vectors to also support specifications of the form
SOFR
/
designating all segments of all multi-segmented wells at all times.
Expand SummaryConfig unit test to exercise this extended record
processing mode.
This commit extends the SummaryConfig class to recognise a small
subset of segment-related summary vectors. In particular, this
brings support for 'SGFR', 'SOFR', 'SPR', and 'SWFR'--at least in a
restricted sense. We do not yet support cases like
SOFR
/
which designates all segments in all wells at all times.
The unit testing is presently minimal and must be expanded before
this is ready for inclusion into master. In particular, we only
check that cases like
SOFR
'PROD01' 1 /
/
generate the expected summary vector nodes (class SummaryNode).
This commit extends Opm::data::Wells to include a set of output
vectors for well segment information. At present we define output
structures for segment rates and segment pressures. The immediate
use case is properly assigning restart vector items RSEG[8 .. 11],
but these same values are also usable for outputting the summary
vectors SPR, SOFR, SGFR, and SWFR. Future expansion is likely.
If the keyword is present then the transimissibilities of the corresponding NNC
entries will be scalled with the factor specified via EDITNNC. Multiple entries
for the same cell pairs are allowed and will result in multiple scalings.
Cell pairs specified in EDITNNC that are not present in NNC are silently ignored.
