In combination with the relevant changes in opm-common this
prevent flow in binary Linux packages from having a timestamp in the
executable that changes with every rebuild.
With the changes in opm-common one can now set the variable
OPM_BINARY_PACKAGE_VERSION to a meaningful version string (Debian
11.2: 2021.10-4). If that is done and flow is built from tarballs it
will now not have a time stamp and print the package version to the
PRT file. E.g.
Flow Version = 2021.10 (Debian 11.2: 2021.10-1)
Instead of always using site-packages we query the sitepackages path
from Python. If it matches dist-packages then we use dist-packages if
we install below /usr, otherwise site-packages is used.
This will also make sure that the Python files end up in the same
location as for the ones of opm-common. This should make using them
easier.
There was a fallout when skipping concating these files to the
default ones (PR #1708). We should also have deactivated creating
these files at all. As a result these files appeared in all parallel
runs that were aborted.
This change now prevents creating and logging to these files in
parallel in a default
run (--enable-parallel-logging-fallout-warning=false).
Developers can still activate logging and concating to see whether
everything is only logged on the io process by passing
--enable-parallel-logging-fallout-warning=true.
Closes 3725
Otherwise the definitions determined by CMake are not available to
opm/simulators/linalg/bda/opencl.hpp and choosing the correct header
might fail.
On my system this at least fixes a warning.
Fallout from #3749
Fixes
```
In file included from opm-simulators/opm/simulators/flow/BlackoilModelEbos.hpp:53,
from opm-simulators/opm/simulators/flow/SimulatorFullyImplicitBlackoilEbos.hpp:26,
from opm-simulators/flow/flow_ebos_gaswater.cpp:28:
opm-simulators/opm/simulators/linalg/ISTLSolverEbos.hpp: In member function ‘bool Opm::ISTLSolverEbos<TypeTag>::solve(Opm::ISTLSolverEbos<TypeTag>::Vector&)’:
opm-simulators/opm/simulators/linalg/ISTLSolverEbos.hpp:265:56: error: incomplete type ‘Opm::WellContributions’ used in nested name specifier
auto wellContribs = WellContributions::create(accelerator_mode, useWellConn_);
^~~~~~
```
OpenCL header was included and OpenclKernels used unconditionally
in WellContributions.cpp. As this file is compiled if CUDA is found,
too it lead to undefined references for e.g. cl::CommandQueue if
opencl headers were there and compile error if not.
Removed message in amgclbackend was:
warning: catching polymorphic type ‘class
boost::property_tree::json_parser::json_parser_error’ by value
[-Wcatch-value=]
We still request Standard version 1.2 only.
We need to use KernelFunctor instead of make_kernel.
In addition cl::Sources now works on std::string and
does not support std::pair<const char*, in> anymore.
With dune-fem the type of the grid view is
Dune::Fem::AdaptiveLeafGridPart and not the LeafGridView
of the grid. The old approach therefore did not compile
as we passed the wrong view.
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.
This is needed for distributed wells to save most of the code
from checking whether a perforation is in the interior.
We add new methods compressedIndexForInterior that return -1
for non-interior cells and use that for the wells. This restores
the old behaviour before 1cfe3e0aad
We decide whether to write tracer concentrations based on the size
of the tracerConcentrations_ container. Hence we need to make sure
that its size is zero after the concentrations have been written
and now resize the container to reflect that.
Before this change only the container inside tracerConcentrations_
were moved (and hence made empty) and next tiem we passed empty
containers to the output writing functions (which in parallel
triggered an assertion).
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.
This saves some (expensive?) lookups that already have been done
in the well model. We had to make the well_container accessible from
the well model for this.
Using the perforation data will automatically make sure that the
perforations are not shut and reside on this process in a parallel run.
There cannot happen any collective blocking communication within a
parallel try-catch clause if exceptions might be thrown before the
communication. The communication has to either be reached by all
processes or no processes.
Although not declared as such, prepareTimeStep seems to be an internal
function (despite usage in a test) and hence error control can be done
in code calling it.
There was the following problem with the try-catch approach taken:
The calling site `BlackoilWellModel::assemble` looked like this:
```
OPM_BEGIN_PARALLEL_TRY_CATCH();
{
if (iterationIdx == 0) {
calculateExplicitQuantities(local_deferredLogger); // no parallel try-catch
prepareTimeStep(local_deferredLogger); //includes parallel try-catch
}
updateWellControls(local_deferredLogger, /* check group controls */ true);
// Set the well primary variables based on the value of well solutions
initPrimaryVariablesEvaluation();
maybeDoGasLiftOptimize(local_deferredLogger);
assembleWellEq(dt, local_deferredLogger);
}
OPM_END_PARALLEL_TRY_CATCH_LOG(local_deferredLogger, "assemble() failed: ",
terminal_output_);
```
calculateExplicitQuantities had no parallel-try-catch clause inside,
but prepareTimeStep had one.
Unfortunately, calculateExplicitQuantities might throw (on some
processors). In that case non-throwing processors will try to trigger a
collective communication (to check for errors) in
prepareTimeStep. While the one throwing will move to the
OPM_END_PARALLEL_TRY_CATCH_LOG macro at the end and also trigger a different
collective communication. Booom, we have a deadlock.
With this patch there is no (nested parallel)-try-catch clause in the
functions called. (And if an exception is thrown in prepareTimeStep, it
will be logged as being an assemble failure).
The other option would have been to add parallel-try-catch clauses
to all functions called. That would have created a lot more
synchronization points limiting scalability even further.
Not a big fan of Macros but here at least they seem ot be the only
option. The problem is that the catch clauses must all catch the same
exceptions that have a entry in ExceptionType, because they might be
nested. In addition we did not have a catch all clause, which is added
now and is needed in case a called method throws an unexpected exception.
For 10 Million cell problems my compute server (with 128 GB Ram)
starts to swap, when I use debugging tools in parallel runs. I assume
that this might get an issue for others, too.
Now we consistently use unordered_map for the mapping.
Previously, exceptions happening at this stage have deadlocked
flow. E.g. UniformTabulated2DFunction in opm-material throws
a NumericalIssue if the values passed are outside the tabulated
reason. This function is e.g. called in 2-phase CO2-storage cases
during BlackoilModel::initializeWellState
BTW: This is only the first step as it is not very user friendly that
a simulation aborts at this (late) stage.
We got compile errors like:
/home/build/opm-simulators/opm/simulators/linalg/FlexibleSolver1.cpp:24:1: required from here
/usr/include/dune/istl/ilu.hh:140:29: error: 'double' is not a class, struct, or union type
without this patch.
Hence we use the new internal ILU functions if available.
If there are unknown keywords and the parser throws an exception
then we nevertheless broadcasted the eclipseState and schedule.
Unfortunately, these might be null pointers in this case and
the serializer will run into a segmentation fault (e.g. when
serializing the non-existent TableManager)
Broadcasting is now only done if parsing was successful.
Unfortunately, we cannot us the imported targets. They add some compile
parameters using generator expressions based on the CXX_COMPILER_ID.
While we are using the system CXX compiler for most of the stuff, some
cuda code is compiled with nvcc which at least for some versions does
not support -Wno-catch-value (which gets passed as normal compiler
option).
Markus Blatt