This commit enables outputting non-linear convergence metrics, i.e.,
the MB and CNV values, per phase, for each non-linear iteration in
each timestep. If the user passes the option value "iterations" to
the --extra-convergence-output command line option, this commit will
create a new output file, CASE.INFOITER, that holds
* report step
* time step within that report step
* elapsed time
* MB and CNV values per phase
* well convergence status
for each non-linear iteration.
We use an asynchronous file writing procedure and confer ownership
of the report step's unprocessed convergence reports to this
procedure just before the end of
SimulatorFullyImplicitBlackoilEbos::runStep()
At that point, the convergence reports are about to go out of scope.
The asynchronous protocol uses a dedicated queue of output requests,
class ConvergenceReportQueue, into which the producer-i.e., member
function runStep()-inserts new convergence reports and from which
the output thread, ConvergenceOutputThread::writeASynchronous(),
retrieves those requests before writing the file data.
This enables outputting a formatted record of the limiting MB and
CNV quantities as time and non-linear iterations progress. This, in
turn, is intended for diagnostic and analysis purposes and will not
be output unless specifically requested.
In particular, add a new type,
ConvergenceReport::ReservoirConvergenceMetric
which captures the convergence metric type (MB or CNV) along with
the associate phase and numerical value of the convergence metric.
We add a vector of these convergence metric objects as a new data
member of the ConvergenceReport.
Finally, foreshadowing the intended use case, also store the report
time in the ConvergenceReport object.
In some models there will be only a few cells with rather high pore volume representing the numerical aquifer. Including them (as non-violated cells) in the ratio will make the ratio lower than without the aquifer there and might lead to accepting vectors as converged when they should not.
As multisegment wells may throw in applyUMFPack this is now needed and
the exception needs to communicated to all processes. We do this in
the linearize method of the well model.
Before this change this is what could happen:
- The process with the exception would have chopped the time step
- The others would have successfully setup the systems and entered the
linear solve
This poduced a deadlock. One processes was waiting in
OPM_END_PARALLEL_TRY during the setup of the shorter time step and in
collective communication during the setup of the linear solver for the
unchopped time step.
