Adding explicit input specification of water-gas ratio (RVW) and RVW output plus simulator gas-water system with salt precipitation and water evaporation for
- add parameter for which toolset to use
- build against openmpi3
- build with python support
- add boolean flags for the different mpi builds (mostly for testing)
- add parameter for appending extra token to package names.
this can be used for allowing multiple versions to be installed on the
same system.
Sometimes the potentials are inaccurate as a safty measure we
also check that the rates are violated.
The rates are supposed to be less or equal to the potentials.
If no cell has a valid corner-point geometry, typically caused by
using GDFILE to read non-finite data such as all ZCORN = -1.0E+20,
then we must not attempt to generate a grid structure. If we do, we
will typically just fail somewhere deep down in the corner-point
processing code and generate a diagnostic message that's hard to
decipher.
With this commit we instead output a diagnostic message of the form
Failed to create valid EclipseState object.
Exception caught: No active cell in input grid has valid/finite cell geometry
Please check geometry keywords, especially if grid is imported through GDFILE
This may not be a lot better than the original diagnostic
Processing grid
flow: ${ROOT}/opm-grid/opm/grid/cpgpreprocess/preprocess.c:768: is_lefthanded: Assertion `! searching' failed.
Aborted (core dumped)
but does at least suggest that the grid data may be faulty.
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.
