Needed to prevent an exception. Apparently both the value and usage
sting must match each time we register a parameter no matter
whether the template parameters differs or not.
- 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)
