We stored 3 copies of each cell centroid in axisCentroid. This seemed
to be a waste of memory and also made the function distanceVector_ hard
to understand.
With this change we omit this copy of information and simplify distanceVector_
The simulation will just chop the time step and continue.
Note, that the error count in the PRT file is used by engineers to
decide whether a simulation was successfull. Hence the error count
should not be increased here.
Nearly all exceptions throw when computing well potentoals will not
abort the simulator but result in timestep chops. Hence those should not be
counted as errors (e.g. by calling the OPM_*THROW* macros) and be
reported in the PRT file.
This change will cause at least two more occurences (in
MSWellHelpers) to be treated as problems. For this we added a new
helper function.
If we use transmissibilities for loadbalancing, then we calculate
transmissibilities twice. First on the global grid before
loadbalancing and then on the local grid after that. This is the
default. In this case all warnings will be shown correctly when
calculating the global transmissibilities.
If the user requests the same weights for all faces (command line
parameter --edge-weights-method=0) then the transmissibilities are only
calculated on the loadbalanced grid. Unfortunately, in this case only
rank 0 will issue warnings for his part including the false positives
mentioned below.
Due to load balancing many NNCs might be stored on another process,
but we still use all EDITNNC entries when computing transmissibilties
locally. Hence when applying EDITNNC on the loadbalanced grid we
will issue warnings for cases where there are no problems (e.g. NNC
between two overlap cells.
With this PR we will only warn when computing the transmissibilities
for the first time. For the default settings this will remove spurious
and duplicate warnings.
Not that for --edge-weights-method=0 nothing changes and we will still
see only warnings for the first rank including spurious one.
This is a follow up of the fix in #5414.
The comment said that the ordering of the compressed index of cells is
coherent with the cartesian index. THis is not the case in parallel
where cells in the overlap/ghost region might be ordered last (default).
In the test methods of the test suite we construct a new logger that
logs to a local stringstream. This logger will be stored in a static
map and hence live longer that the test method and the stringstream.
Some methods use Opm::Log::MessageType::Note, others
Opm::Log::MessageType::Warning for adding the loggging backend . There
is one map per MessageType and sometimes (e.g. previous method used Note
and this one uses Warning) we will log to the old logger with dangling
references.
This problem materialized in a segmentation fault on ppc64el architecture.
The step size might still need to be smaller than suggested to not
simulate beyond the end of the current report step. To ensure this we
now use AdaptiveTimeSimulationTimer::provideTimeStepEstimate which
will limit it and also make sure that subsequent time steps will not
get to small either.
If we would try that then we would index vectors with index -1 and
possibly overwriting other system information. This was the case for
some models resulting in cryptic errror " corrupted size vs. prev_size"
Now we simply do nothing for NNCs.
We accomplish that by passing the module version as a string to the
constructors of LogOutputHelper and EclGenericOutputBlackoilModel
instead of calling moduleVersionName() in LogOutputHelper. That way
moduleVersionName is not needed by libopmsimulators anymore and
compilation works again for people requesting shared libraries via
CMake's BUILD_SHARED_LIBS variable.
Up to now this information is only output to standard out.
To help with debugging and replicating (e.g. in case of crashes)
without saved standard putput, we now also print the imformation about
MPI processes and OMP threads to the PRT file.
For this particular model WetGasPVT::saturationPressure did throw
because convergence in the newton solver is not reached in 20
iterations. Unfortunately, the exception was only seen on one MPI rank
and the others continued.
With this commit we communicate the problem and throw on all MPI
processes. Time step will be cut as a result.
Previously, if the problem occured on an MPI process with rank other
than zero the the logging would not seen (at least in the output
files). Now together with the previous commit the problem should be
logged together with the well name and calling method.
For multi segment well the underlying call to
MultisegmentWell::updateWellStateWithTarget (at least if
updateWellStateWithTHPTargetProd is called for a producer under thp
control) might throw as there might be a singular matrix during the
solve needed in MultisegmentWell::iterateWellEqWithControl.
Previously, if that happened then the MPI process where it happened would
stop the nonlinear iteration as failed and try with a chopped time
step. The others might go one with the current time step and we would
see MPI errors about truncated messages.
Now we communicate any exception happening during this part of
WellModel::updateAndCommunicate and all processes will stop the
nonlinear iteration as failed and chop the time step.
We are experiencing singular matrices when solving mulisegment wells
sometimes. In that case (here during
BlackoilModelEbos::assembleReservoir <-
BlackoilModelEbos::initialLinerization <-
BlackoilModelEbos:::nonlinearIterationNewton ) an exception is thrown
when updating the controls of a well.
The problem here is that this exception only happens on one
process. That one goes to the catch block in
NonLinearSolverEbos::step, marks the nonlinear solve as failed and
cuts the time step. The others move to the collective communication
below. Somehow and somewhen all end up in a non-matching collective
communication with different data types and we get an MPI Error that
the message was truncated.
Now all processes will throw, terminate the nonlinear solver and cut
the timestep as it should be.
Using bool here is at least frowned upon. To be honest, I have no idea
what happens underneath here if we pass a bool. In contrast to other
pod types we do not associate it with a builtin type of MPI (not even
sure what to use). Hence we probably create a custom type for sending
and receiving. That should work. But I have no idea what will be used
for summation.
BTW: I am debugging a case that previously crashed and now suddenly
works and this seems to be the only relevant change I made in the
meantime.
Checking int return types of MPI functions is inefficient. The default
error handler will abort the problem. If somebody changes that, then
they should know what they are doing.
Markus Blatt