- use imported target for linking
- use separate damaris cmake script
- handle HAVE_DAMARIS config variable in the usual way
fixing issues when user does not provide an outputDir via a command_line
avoid adding damaris's command lines when we dont have damaris
This is necessary because when using Damaris we must have the output dir ready
when we initialize Damaris. In the existing code, this was ensured only
from the setupLogging() call.
Damaris initialization is added after InitMpi but before starting the simulation. Damaris will invoke a separate core for writing in
parallel and leave the rest of cores for the simulator. The main changes are in main where start_damaris and then in eclwriterm where
we use damaris to output the PRESSURE. To test Damaris one can use --enable-damaris-output=true and to use parallel HDF5 one can use
--enable-async-damaris-output=true (false is the default choice)
This is only instantiated for two-phase gas/oil and for 3-phase blackoil.
Runtime safeguards have been added to avoid the mistake of running with
a simulator combination that silently ignores DIFFUSE.
This is one of several PRs that will rename some command line parameters for greater consistency, as agreed with Atgeirr in #4096
Here we rename FlowNewtonMinIterations to NewtonMinIterations
Moving it ensures it is also done for restart simulation runs. Without
this, the well model will actually initialize the IQs, but only for
owned cells, not overlap/ghost cells, which caused parallel failure.
this is used transferring ownership of setup structures to the
simulator. drop all the flowEbosXXX set deck methods and use the
generic vanguard. also means various structs that were only passed
in the blackoil simulator are now passed in all simulators.
also shut unsolvable wells during iterations as default
Note however that getWellConvergence return false if a well is unsolvable
i.e. it will cut the timestep and redo the iteration if the well is unsolvable
and only shut it completly if the time step is below the
MinTimeStepBeforeShuttingProblematicWellsInDays (default 0.01 days)
Adding explicit input specification of water-gas ratio (RVW) and RVW output plus simulator gas-water system with salt precipitation and water evaporation for
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.
