Skeleton in place for increased flexibility in methods and usage.
(So far behaviour choices are hardcoded, though.)
Added relative flux thresholding to existing limiter to avoid flux noise
strongly affecting solution. For example no-flow boundaries could be treated
as inflow boundaries and make the minimum upwind face limiter meaningless.
There is a different problem that needs fixing, however:
Flux inaccuracies (for example on boundaries) may tag some
face as inflow face for a cell, even if it should have been
no-flow. This may let the cell avoid limiting, even though it
should have been limited according to the proper inflow faces.
The limiter is experimental and unfinished, untested work in progress.
Limiter is therefore inactive by default.
Also fixed a minor bug: use_cvi_ was not initialized.
opm/core/eclipse/EclipseGridParser.cpp
opm/core/eclipse/EclipseGridParser.hpp
- New keywords: ENDSCALE SCALECRS SWCR SWL SWU SOWCR KRW KRWR KRO KRORW
opm/core/eclipse/SpecialEclipseFields.hpp
- Parsers for ENDSCALE and SCALECRS.
opm/core/fluid/BlackoilPropertiesFromDeck.cpp
- Consistency check: ENDSCALE implemented for SatFuncSimple only.
opm/core/fluid/SatFuncGwseg.hpp
opm/core/fluid/SatFuncSimple.hpp
opm/core/fluid/SatFuncStone2.hpp
- Accomodate "default" values for scalable parameters.
- For SatFuncGwseg and SatFuncStone2 the associated functionality not
yet supported and the variables are dummies to satisfy the compiler.
opm/core/fluid/SatFuncSimple.cpp
- Initialisation for scalable parameters.
- Evaluation of relperms: Use (1-so) for evaluation of oil-relperms.
(For scaled arguments sw and so do not necessarily add to one.)
- TODO: SatFuncGwseg.cpp and SatFuncStone2.cpp for oil-water systems.
opm/core/fluid/SaturationPropsFromDeck.hpp
- Struct to accomodate cell-wise scaling factors.
- Two flags indicating scaling and method.
- Methods for parameter initialisation and scaled relperm computation.
opm/core/fluid/SaturationPropsFromDeck_impl.hpp
- Initialize scaling options and relevant cell-wise scaling factors.
- Relperm evaluation modified for possible end point scaling.
This means that the class does expect source terms that are just that, and not
'transport source' terms that include boundary inflows (like the transport
solvers expect). This is also consistent with the behaviour of the DG version.
Should now be in sync with cfs_tpfa_residual C interface. Simple well
gravity model implemented.
More flexibility in well gravity models would be a natural future extension.
We previously ignored effects of gravity in the calculation of the well
connection fluxes (i.e., perforation fluxes). This commit includes
those effects where appropriate.
Specifically, the tests
if (!wells->type[self_index] == INJECTOR)
if (!wells->type[self_index] == PRODUCER)
produced the expected results *only* because INJECTOR==0 and PRODUCER==1
in the WellType enumeration, thus (!INJECTOR == PRODUCER) and
(!PRODUCER == INJECTOR).
Installing the (much) more appropriate
if (wells->type[self_index] != INJECTOR)
if (wells->type[self_index] != PRODUCER)
is not only more readable, it is also future-proof and scales better if
we ever introduce new WellTypes (e.g., a MONITOR).
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.
