It complains about not finding a match for the pair<> template class,
because the first parameter (this) is allegedly const. However, this
isn't a const method, so I suspect it is a compiler bug.
In order to move on, I slap on a harmless cast which will make this
particular compiler happy, and which should have no effects elsewhere,
but put it in a #if..#else..#endif macro to avoid warnings on others;
hopefully this also makes it easier to spot and remove in the future.
The class TransportModelTracerTofDiscGal now uses
VelocityInterpolationInterface, and acts as a factory
internally, choosing an interpolation method depending on
the parameter 'use_cvi'.
Order of arguments for computePhaseFlowRatesPerWell() was wrong.
This fix was done previously for SimulatorCompressibleTwophase,
but the incompressible sim was ignored.
Also added an ASSERT that may help catch some misuse.
In the Wells struct, production rate control targets must be negative
(and injection rate control targets are always positive).
In the WellsGroup classes, there are separate variables for injection
and production, and all rates are positive. Therefore, upon adding or
modification of a production rate control, the negated value must
be used.
This installs a measure of safety on the part of the interface in that
the caller is free to dispose of the wells object upon returning from
the WellsManager constructor.
Basis functions, quadratures and velocity interpolation are basic versions,
not handling any higher than DG(1) for now. These are currently in helper
classes and functions. The code in the main solver class is written with
the aim of supporting DG(n) generally.
In DUNE 2.2 FieldVector::size changed from being a member to being a
method. A compatibility warning is issued if you include the relevant
headers.
This warning can be silenced for DUNE modules by using passing the
option --enable-fieldvector-size-is-method to ./configure. This patch
effectively does the same, but through a macro definition.
The CompressibleTpfa class always passes a non-null `forces->wells'
object to the constructor, assembly, and reconstruction routines but
uses ``forces->wells->W == 0'' to signify a simulation model without
wells. This is, arguably, an error in the CompressibleTpfa class but
one that does not require a lot of work to support in the
cfs_tpfa_residual module.
Insert the extra tests in an effort to honour the ``liberal in what you
accept, strict in what you produce'' principle.
The user will legitimately want to run models that do not specify wells
(e.g., using boundary conditions). While we do not yet fully support
that configuration (no wells), we absolutely must not crash by
dereferencing null pointers or generating pointers into ::empty()
std::vector<>s.
This commit installs the required guards needed to avoid said failure
mode.
Now you can actually shut and open wells with WELOPEN. The following
caveats apply:
- this may interact improperly with group controls,
- dynamic usage of WCONINJE/WCONPROD should not be mixed with WELOPEN.
Bhp is now initialized to bhp target for bhp-controlled wells.
Mobilities and pvt properties are now calculated from
well perforation pressure and injection specifications for
injectors, producers still use cell properties as before.
Conflicts:
Makefile.am
opm/core/fluid/BlackoilPropertiesFromDeck.hpp
opm/core/fluid/SaturationPropsFromDeck.cpp
opm/core/fluid/SaturationPropsFromDeck.hpp
opm/core/fluid/blackoil/BlackoilPvtProperties.cpp
opm/core/fluid/blackoil/BlackoilPvtProperties.hpp
opm/core/fluid/blackoil/SinglePvtDead.cpp
This merge combines three more-or-less orthogonal features
for saturation tables: the option to use StoneII or Simple
three-phase behaviour, the option to fit a spline or not,
and finally setting the number of samples used (if spline
fitting).
Interfaces have changed, the most top-level one being
that BlackoilPropertiesFromDeck::init() now also takes
a ParameterGroup argument.
Introduced a simple fluid which has no problem with strange black oil behavior.
Intended for testing, but for now it is used in SaturationPropsFromDeck.
Recall that the class that used to be called SinglePvtDead has
been renamed to SinglePvtDeadSpline. If 'props_use_spline' is true,
that class is used (this is the default), which makes a monotone
spline that is uniformly, densely sampled. The new class simply
uses linear interpolation in the input tables.
