This is intentionally black-oil specific because we presently do no
know how to handle other cases (e.g., more phases or number of phases
different from number of components).
The second input of initBlackoilStateFromDeck that computes surface
volumes based on gas/oil ratio is changed from
BlackoilPropertiesInterface to Props. To avoid duplication with the old
initBlackoilStateFromDeck its name is changed to
initBlackoilSurfvolUsingRS.
Add new function is added that computes saturation from surface volumes
solving z = As for each cell. This function is used to compute an
intial guess to the saturations in initState_impl.hpp.
The 'comp_term' is supposed to be a total divergence term, which is supposed
to be zero for incompressible flow. It was added for improved robustness in
stagnant areas, but as implemented it would not be computed properly for
oil injection scenarios, due to the convention for two-phase transport
source terms (positive terms are inflow of first phase [water], negative
terms are total outflow).
The WellsManager class handles INJECTORS by assigning a phase
distribution (W->ctrls[i]->distr) that coincides with the injected
fluid for the corresponding well (e.g., {1,0,0} for WATER injectors in
a three-phase WATER/OIL/GAS simulation). This, however, meshes poorly
with the restriction that all phase components must be ONE in the case
of wells constrained by total reservoir volume flow targets (RESV)
that was introduced in commit b7d1634.
This change-set limits the restriction on phase distributions to
PRODUCERs only and is a tentative solution to GitHub PR #360.
Otherwise the compiler will probably give us a warning that these
pragmas are unknown. By default that warning is disabled with our
own build system, but we also want to be able to link to our library
without incorporating the entire build system too.
To avoid deprecation warnings the number of smoothing steps was passed
through the Criterion instead of directly to the constructor in commit
a7f32b934b.
However, due to an insufficient test matrix this was not tested using
the fast AMG variant of DUNE so it breaks the builds if
`-DHAS_DUNE_FAST_AMG` is defined.
This change should apply the same type of change to this branch as for
the others. The number of smoothing steps is put into a constant to
avoid the magic number 1 to appear in too many places (although I am
not sure the number for pre- and post-smoothing always should be the
same).
If a function is used by a template but this template is not
instantiated, the function will still be defined in the header
of a module but it won't be callable because it is in an anonymous
namespace and thus we get a warning.
This only happens in Clang; GCC consider functions referenced from
templates as used.
fixup! Don't warn about functions not emitted
