on CLang 3.4 svn this produced
```
/home/erne/src/opm-core/opm/core/pressure/fsh.h:20:9: warning: 'OPM_FSH_HEADER_INCLUDED' is used as a
header guard here, followed by #define of a different macro [-Wheader-guard]
```
which is correct...
this simplifies the template meta programming a bit. (Which does not
mean that it suddenly gets easy.) The main motivation for this work is
to make the splices feature work properly which allows eWoms to
properly select the spatial discretization at any point.
Further, the number of type tags a node can inherit from now is truely
unlimited thanks the the generic tuple reversal class provided by
https://sydius.me/2011/07/reverse-tuple-in-c/ . (before, the maximum
number of nodes from which a type tag could inherit was 11, so this
limitation did not really matter in practice.)
This code is run unconditionally each time we do a reconfigure; if the
option is added at each time, they will accumulate (needlessly) on the
command-line, making it harder to inspect the log.
If the module root is not explicitly specified, the loading of its
configuration is delegated to a find module, which does a heuristic
search in known/surrounding directories. Most OPM modules use the
common logic in OpmPackage; this patch configures the search
specifically for opm-autodiff.
If we have checked out a newer Eigen3 directory in a sibling directory
to ours, assume that this is because the system version is obsolete and
that we want to use this one instead.
Eigen3 is a template-library, so we must compile the source code
directly together with ours instead of linking to a library.
If the build script gives us the location of a "built" Eigen3,
meaning a directory in which CMake has been run, locate the true
source directory from the cache entries.
Commit a5a4d7b introduced density and viscosity evaluators into the
SinglePvtInterface that accepted an externally assignable condition
to distinguish saturated from unsaturated cases. As a result of a
few low-level technical problems with that approach, this commit
changes those affected interfaces to use the black-oil specific
'PhasePresence' facility of commit a033329 instead.
Update tests and callers accordingly.
Suggested by: @andlaus
Approved by: @atgeirr
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).
Functions for volume factor and viscosity that explicitly take a boolean
variable indicating whether the fluid is saturated or not is added to
the SinglePvtInterface.
Corresponding changes are done in the dependent PVT files.
The new functionality is tested in test_blackoilfluid
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 calculated gas resolution factor is compared to
the tabulated resolution to check wether the oil is saturated
or not. The new test judges equality as saturated. This
is cruscial as the gas resolution is set to equal the tabulated value
for the saturated case in the appleyard process.
The relperm of water and gas is now evaluated at the water and gas
saturation, respectivly. The relperm of oil is still a combination of
the the 2p relperm of water/oil and oil/gas.
If we want to index into two arrays that has been concatenated (for
instance oil phase pressure continuously, then water phase pressure
continuously), then this variant (courtesy of @bska) will cover both
variants (intermixed striding (where offset < stride) and sequentially
striding (where offset > stride)).
We are interested in how many records there are, since we extract one
item per record. The offset is just used to index into each record, and
doesn't affect the total number of records.
If the output routines are called at the right place in the simulator,
then the numbering scheme coincide with that of Eclipse, and no
adjustments are necessary.
The step number is zero before the first timestep has been taken, and
one after. The step number is one before the second timestep has been
taken, and two after. This was not clear from the text.
