this basically means using Opm::EclipseState instead of the raw deck
for these keywords.
with this, property modifiers like ADD, MULT, COPY and friends are
supported for at least the PERM* keywords. If additional keywords are
required these can be added relatively easily as well.
no ctest regressions have been observed with this patch on my machine.
In summary:
- added RsFunction (base class),
- made NoMixing, RsVD, RsSatAtContact inherit RsFunction,
- RS and RV are no longer template arguments for EquilReg class,
- EquilReg constructor now takes two shared_ptr<Miscibility::RsFunction>,
- use of constructor updated, mostly using make_shared.
This commit adds support for assigning the initial phase pressure
distribution to a subset of the total grid cells. This is needed in
order to fully support equilibration regions. The existing region
support (template parameter 'Region' in function 'phasePressures()')
was only used/needed to define PVT property (specifically, the fluid
phase density) calculator pertaining to a particular equilibration
region.
This commit adds a simple facility for calculating initial phase
pressures assuming stationary conditions, a known reference pressure
in the oil zone as well as the depth and capillary pressures at the
water-oil and gas-oil contacts.
Function 'Opm::equil::phasePressures()' uses a simple ODE/IVP-based
approach, solved using the traditional RK4 method with constant step
sizes, to derive the required pressure values. Specifically, we
solve the ODE
dp/dz = rho(z,p) * g
with 'z' represening depth, 'p' being a phase pressure and 'rho' the
associate phase density. Finally, 'g' is the acceleration of
gravity. We assume that we can calculate phase densities, e.g.,
from table look-up. This assumption holds in the case of an ECLIPSE
input deck.
Using RK4 with constant step sizes is a limitation of this
implementation. This, basically, assumes that the phase densities
varies only smoothly with depth and pressure (at reservoir
conditions).
this has recently been moved there. Since redundancy is considered to
be bad, switch eWoms to it.
I've tested this with Norne: No measureable difference, as expected.
for some reason the results have changed. (IMO, the new ones look more
correct in paraview.) The reason this was not discovered earlier is
that this test depends on the presence of dune-alugrid and the CI
infrastructure does not deal with this.
the reason is that cmake cannot file(COPY) them. this is probably due
to constraints of a crappy operating system that is made by a
microscopical and tender company which is based close to Seattle.
there seems to be only a *very* limited amount of interest, the code
of the model is quite complex and there are currently no suitable
discretizations for free-flow equations in eWoms (i.e., the model
tends to be very unstable and oscillates a lot). Combined, all of this
makes maintaining this model a pain in the back, so let's remove it
some interest in these kinds of problems surfaces and until
appropriate discretizations -- like staggered grid methods -- are
available.
This works by having a "focus degree of freedom" during
linearization. When evaluating the local residual, all derivatives of
the residual/fluxes are with regard to the primary variables of that
DOF.
The two main offenders were the Forchheimer velocity model and the
model for the Stokes equations. To ensure that they continue to work,
the "powerinjection" and the "stokestest2c" problems are now both
compiled and tested with both, automatic differentiation and finite
differences, and the results of these tests is compared against the
same reference solution.
The majority of the time required to develop this patch was actually
required for testing: All tests compile and pass with debugging and
aggressive optimization flags with at least GCC 5, GCC 7 and clang
3.8, as well as Dune 2.3 and 2.4. Also, the results of flow_ebos stay
identical for Norne whilst the performance difference is below the
measurement noise on my machine. (the version with this patch applied
was actually about 1% faster.)
this belongs to the `tests/data` directory, not into the toplevel
`data` directory. Also, the input ART file for this has been renamed
to `fracture-raw.art` to avoid race conditions.
for the vertex-centered finite volume discretization, the relevant
position for calculating the gradient is *not* the position of the
center of the *sub*-control volume, but the center of the whole
control volume.
Since this patch changes the gradients of all VCFV simulations that
use twopoint gradients, quite a few new reference solutions are
required by this PR. I've looked at all of them manually and made sure
that they look reasonable. (The PR also includes a new reference
solution for the test for the adaptive finger problem -- which uses
ECFV -- but that's because the grid refinement seems to be quite
sensitive to the solution proceedure for that problem, not because
there's any difference in the solutions that can be noticed visually.)
note that all simulations that use element centered finite volume
discretization because there sub-control volumes are identical to full
control volumes. In particular, ebos -- and by extension `flow_ebos`
-- is unaffected because it does not even use that code.
