IMO the term "vanguard" expresses better what these classes are
supposed to do: level the ground for the cavalry. Normally this simply
means to create and distribute a grid object, but it can become quite
a bit more complicated, as exemplified by the vanguard classes of
ebos..
The new eclwriter output and restart using the eclIO from opm-output
All tests in opm-simulator pass and
MPI restart works.
Standard initialization is done prior to restart in order
to compute correct initial thpressure values. This is not
necessary if thpressures are written to the restart file
TODO: Some trivial fields are written out in order mimic legacy code,
this should be cleaned up
TODO: Output of wells, FIP, NNC is still done in opm-simulators.
This should be moved later.
this just moves the hydrostatic equilibrium code from its historc
location at opm/core to ebos/equil and adds minimal changes to make it
compile. this allows to clean up that code without disturbing the
legacy simulators.
Apply swatInit in the initialization
Stop using the equilGrid in the initialization code
Keep The initialFluidState until end of first time step to make it
possible for flow to output it.
This reverts commit c873e8c92da389bc1d6bc4ed2a5241faddfa7630.
since OPM/opm-simulators#1287 has been merged there are no "in tree"
upstreams which use that mechanism anymore.
this now works with the unmodified master version of flow from
opm-simulators. we take the liberty to emit a deprecation warning,
though. this complicates things quite a bit.
This gets rid of some special-purpose code in generic places (i.e. the
`SimulatorParameter` class) and no special hacks to the property and
parameter system are required anymore.
Adds a conservation equation for polymer.
Polymer concentration in the water phase is used as primary variable
The polymer influences the viscosity of the water, and leaves gas and oil
uneffected.
A shear multiplier is computed if PLYSHLOG and/or SHRATE is specified
based on either velocity or shrate.
The shear multiplier effects the water and polymer viscosity.
Tested and verified on the test cases in polymer_test_suite
this reduces the number of direct deck accesses in `EclProblem` in
favour of `EclipseState`-grid properties. as far as i can see,
directly using the deck object cannot fully be avoided because
`EclipseState` does not seem to provide internalized versions of all
these keywords yet.
- initialization only via Ecl Deck
- adds modification of relperms and cap-pressures for miscible runs
- adds TL mixing model for effective viscosity and density calculations
Tested on SPE1CASE2_SOLVENT_MISC_TL, SPE9_CP_CO2_MISC_TL, SPE5CASE1-3
and SPE3CASE1_SOLVENT_MISC
Conceptually this is IMO pretty questionable, since it adds a second
"gas phase" that does not mix with "ordinary" gas. I suppose the
reason why this extension was conceived by E100 is that if all you
have is hammer, everything looks like a nail...
Functionality-wise, this patch is still not fully complete because
miscibility of the solvent "phase" is not yet implemented. As far as I
can see, the API changes required by miscibility are quite limited,
though.
if the initial solution is explicitly given by the deck using the
PRESSURE, SWAT, etc. keywords, the specified state can be
thermodynamically impossible. To avoid inconsistencies, we use a flash
calculation to find a state that is in thermodynamic equilibrium and
exhibits the same masses as the explicitly specified solution. Since
the flash solver needs to compute quantities for all fluid phases, but
two-phase blackoil simulations usually do not specify the properties
of one phase, the flash solver crashed. This patch works around that
issue by simply not using the flash solver in the twophase case, i.e.,
the explicit initial condition must be thermodynamically consistent in
order to produce the stable results for a different choice of primary
variables.
