I consider the blackoil model enums to be pretty low level while the
"FluidProperties" code is IMO quite high level. this, using the latter
to define the former constitutes a layering violation IMO. note that
the fix is to simply use the enums from opm-core directly.
Methods that returns the scaled critical gas (SGCR) saturation and the
scaled critical gas in oil saturation (SOGCR) is added to
BlackoilPropsAdFromDeck and BlackoilPropsAdInterface
A test is added in test_boprops_ad and fluid.data is modified to make
the test non trivial.
Since the refactoring to using opm-material a material law manager for
the global grid was used. This meant that the properties used for
elements of the local grid were wrong. With this commit we set up a
manager that is based on the local grid only.
Remaining method is the one taking AD objects. This modification
required changes to a few more places than anticipated:
- RateConverter
- FullyImplicitBlackoilSolver::computeWellConnectionPressures()
In these places, the call now is a little more complex and there
might be a very minor performance loss, until we optimize the
bX() functions to check for the no-derivatives case.
This change has been made in both BlackoilPropsAdInterface
and BlackoilPropsAdFromDeck. Only remaining overloads are
those using AD objects and passing the PhasePresence for
each data point.
1) swatinit() is changed to setSwatInitScaling() to make it obvious that
we are modifying the props.
2) the descriptions of saturation and pc now makes more sense
3) the method is removed from the sibling class and the interface and
the type of new_props is changed from BlackoilPropsAdInterface to
BlackoilPropsAdFromDeck
5) The same modification is added to sim_fibo_ad_cp
The capillary pressure function in new_props is scaled to match the
capillary pressure function in props.
This is a temporary workaround while the simulator uses two different
property object.
With this commit we add the possibility to start with a global representation
of a simulator that is read on each process and afterwards this presentation
is redistributed among the processors together with the properties and
state data needed to initialize the simulation.
There still is no parallel well handling and no parallel output. But with the
equilibrium example of @dr-robertk and deactivated output we can already
perform parallel runs.
In the parallel simulator we will have to be able adress only poperties on
some part of the global grid. To create thos properties we need to be able
to copy the grid independant data of the properties object and resize the rest.
This commit adds a construct taking a properties object for reading and a
new number of cells to accomplish this.
The initial definition of the phase indices seems to be in
opm/core/props/BlackoilPhases.hpp. Nevertheless there were
several redefinitions of the same or similar enums (either
Aqua, Liquid, and Vapor, or Water, Oil, and Gas). Surprisingly
most often these definitions did not use the original values.
This is bound to break if there is a change upstream.
This patch limits the definition to one place in opm-autodiff,
namely opm/autodiff/BlackoilPropsAdInterface.hpp. To avoid
downstream confusion we define both the Water and Aqua triplets.
In addition we define the maximum number of phases to use at compile
time.
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
When this kw is active, BlackoilPropsAdFromDeck now modifies rvSat
and rsSat curves cell-wise by a power of (sat_oil_cell /
sat_oil_cell_historical_max). Currently, the associated jacobians do
not reflect terms of type d/d_sat_oil, but code for doing this is given
as comments to BlackoilPropsAdFromDeck::applyVap(ADB& r, ...).
i.e. reading the grid properties from EclipseState instead of from the
raw deck. This requires that all deck files exhibit a GRID and a
SCHEDULE section or else EclipseState will throw in the constructor.
