Basic support for this keyword was added in commit
OPM/opm-common@5e3e20c552
and this commit enables running models which use that basic support.
Advanced uses, such as including user-defined arguments for the
multipliers, will still be rejected at the input level.
This commit adds a new stage to the wellData() report function,
assignWellTargets(), which collects the numerical values of the
currently active limits/targets for summary file output purposes.
It is important that we collect these values strictly before we
start mutating the SummaryState object lest user-defined arguments
in keywords like WCONPROD be evaluated seemingly too soon.
Furthermore, it is faster to collect these values on the simulator
side and send them to the I/O rank for file output than to defer the
full calculation to the I/O rank.
This PR switches to calling the SummaryState constructor which is
aware of the value of undefined UDQs (OPM/opm-common#4052) directly.
While here, also sort headers, split some long lines, and prefer
initialisation lists to constructor body assignments.
Commit 0aaa69c6e (PR #5330) was a little too eager in its effort to
handle UDQ ASSIGN operations after action processing[%]. In
particular, the assignments, which alter the internal structures of
the SummaryState and UDQState objects, would happen prior to writing
summary files. In turn, this would make it appear as if the
assignment happened too early. This commit defers UDQ assignments
triggered by action processing until FlowProblem<>::endEpisode() for
two reasons
1. The problem originally addressed in 0aaa69c6e only presented
when the assignment was triggered on the final time step of an
episode (report step), so handling this situation here is a
more targeted approach.
2. Member function FlowProblem<>::endEpisode() is called after we
write the summary file output so any alterations to the
internal structures of the SummaryState will not be visible in
the summary output until the next time step. This is the
expected behaviour.
[%] Insufficient testing by: [at]bska.
Since std::clamp returns a reference we must be careful to not capture
the return value by reference, when there is a temporary among the input
parameters.
For the second change (adding the explicit Scalar return type to a lambda)
this is strictly speaking not necessary, as the lambda's return type is not
a reference, but that is obscure so the change is just done as to clarify.