Instead of unconditionally issuing MPI_Abort if we encounter a fatal
exception, we try to test whether all processes have experienced this
exception and if this is the case just terminate nomally with a exit
code that signals an error. We still use MPI_Abort if not all
processes get an exception as this is the only way to make sure that
the program aborts.
This approach also works around issues in some MPI implementations
that might not correctly return the error.
Multiple messages like this are gone now:
```
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[smaug.dr-blatt.de:129359] 1 more process has sent help message help-mpi-api.txt / mpi-abort
[smaug.dr-blatt.de:129359] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
```
Bu we still see something like this:
```
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[35057,1],0]
Exit code: 1
--------------------------------------------------------------------------
```
Changes
```
Program threw an exception: [/home/mblatt/src/dune/opm/opm-simulators/opm/simulators/timestepping/AdaptiveTimeSteppingEbos.hpp:586] Solver failed to converge after cutting timestep 11 times.
```
to
```
Simulation aborted: Solver failed to converge after cutting timestep 11 times.
```
Which seems more user friendly.
There is a strange interaction when using MPI and OpenMP on some
hardware/MPI implementations. I a serial run omp_get_num_procs() would
return the number of processors but when started under mpirun it would
always return 1.
With this we now allow users to use any amount of threads.
While we reported that we used the number of threads that were passed
on the command line, we never really used it for OpenMP but always
sticked to two unless environment variable OMP_NUM_THREADS was set.
Note that because the ThreadManager in opm-models would always use the
command line option and hence the linearizer would use that number of
threads.
Please note that the only use of OpenMP in opm-common (volume
calculation in EclipseGrid) is not effected by this as it happens
before we set the number of OpenMP threads.
Following commits f4f8c033d and c7016854d (PR #4286), the "vanguard"
no longer maintains an internal Deck data member. Don't pretend
that it does by providing member functions to access that data
member. If someone tries to actually call these member functions
then they will get an unfriendly diagnostic message and a build
failure.
This commit renames the previously introduced command line option
ExtraConvergenceOutput (--extra-convergence-output) into the more
descriptive
OutputExtraConvergenceInfo (--output-extra-convergence-info)
Suggested by: [at]OPMUSER
This commit introduces a new helper class,
ConvergenceOutputConfiguration
which parses comma separated option strings into a runtime
configuration object for whether to output additional convergence
information and, if so, what information to output.
Supported option string values are
* "none" -- Dont want any additional convergence output.
* "steps" -- Want additional convergence output pertaining to the
converged solution at the end of each timestep.
* "iterations" -- Want additional convergence output pertaining to each
non-linar ieration in each timestep.
Option value "none" overrides all other options. In other words, if the
user requests "none", then there will be no additional convergence
output, even if there are other options in the option string.
We add a new option, ExtraConvergenceOutput (command line option
--extra-convergence-output), which takes a string argument expected
to be a comma separated combination of these options. The default
value is "none". Finally, make the INFOSTEP file output conditional
on the user supplying "steps" as an argument to the new option.
Currently the simulator creats the polyhedreal grid from an eclGrid from opm-common
TODO
- make it possible to create the grid directly from DGF or MRST format
- fix issue on norne.
A resubmission of commit 8e4f748 in PR #2403 and PR #2444 and continues
the work in #2690 implementing Python bindings to the flow simulator.
The Python step() method advances the simulator one report step. Before
calling step() for the first time, step_init() must have been called.
A resubmission of commit 11eaa3d7 in PR #2403 and PR #2443 and continues
the work in #2555 implementing Python bindings to the flow simulator.
The step_init() method initializes the simulation. It is required for the
Python script to run step_init() before calling the step() method (which
will be implemented in a later commit).
Clarify usage of member variables in FlowMainEbos.hpp by prefixing with
this->.
Also rebased PR on the current master, and updated
flow_ebos_oilwater_brine.cpp according to the PR.
