as a side effect, two-point gradients are now used by default for the
vertex-centered finite volume discretization. (because P1-FE gradients
require the FE shape functions and those are provided by
dune-localfunctions.)
as a consequence, this triggered an update of quite a few reference
solutions: the differences are measurable, but as far as I can see,
the results are compareable. also, this commit regresses the
performance of the test for the reservoir problem with the vertex
centered finite volume scheme a bit. While I would not bet a house on
the reason, I'm pretty sure that this is caused by the switch from P1
FE gradients to two-point ones.
Note that even though I'm the author of this patch, it shamelessly
rips off substantial parts of the @dr-robertk's patch:
https://github.com/OPM/ewoms/pull/69
this problem did not work properly anyway: it oscillated like hell
(very likely to the spatial discretization used being inappropriate)
and it did not even converge if more than a single iteration was
required.
these are:
- remove the unused methods "baseEpsilon()" and "numericEpsilon()"
from FvBaseAdLocalLinearizer. (they are only meaningful in the
context of finite differences.)
- correct/update some comments
- replace most occurences of Toolbox::createConstant() with
assignments to floating point values to unclutter the code a bit.
i.e., in most cases the initial solution will be written into file
$SIM_NAME-00000.vtu and each time step will be written to the file
with the same number as the one printed during the simulation. (note
that this statement does not apply if the visualization files are not
written for all time steps.)
this broke with 94006531. I actually fixed the reservoir problem
yesterday before pushing 94006531 but forgot to include the fix in my
local branch before pushing. Stupid me!
now, the dune-alugrid module is required if these tests are to be
run. (note that due to the fact that the OPM build system has not been
detecting the legacy alugrid library for a while, the practical
implications of this patch should be small to non-existant.)
this is necessary to allow non-trivial ParameterCache objects with
Local-AD evaluations. So far, the only fluid system in opm-material
which needs this is the Spe5 fluid system (which is unused by eWoms),
but sooner or later this change would have been required anyway.
Note that it is possible that this patch is errornous if Evaluation !=
Scalar for a fluid system that uses a non-trivial ParameterCache
object, but the errors should be relatively easy to fix...
i.e., the simulation for the CO2-injection problem which uses the
flash solver to handle its thermodynamics and element centered finite
volume method as the spatial discretization. The intention is to
ensure that opm-material's NcpFlash constraint solver works with
non-primitive types as Scalars. (or rather: that it will be quickly
detected if it breaks in that case.)
the in-file lists of authors has been removed in favor of a global
list of authors in the LICENSE file. this is done because (a)
maintaining a list of authors at the beginning of a file is a major
pain in the a**, (b) the list of authors was not accurate in about 85%
of all cases where more than one person was involved and (c) this list
is not legally binding in any way (the copyright is at the person who
authored a given change, if these lists had any legal relevance, one
could "aquire" the copyright of the module by forking it and removing
the lists...)
the only exception of this is the eWoms fork of dune-istl's solvers.hh
file. This is beneficial because the authors of that file do not
appear in the global list. Further, carrying the fork of that file is
required because we would like to use a reasonable convergence
criterion for the linear solver. (the solvers from dune-istl do
neither support user-defined convergence criteria not do the
developers want support for it. (my patch was rejected a few years
ago.))
this has slowly become a hassle to support (i.e., it cluttered the
source with many #if's and in particularly the code was not tested
with Dune 2.2 on a regular basis). Also, Dune 2.3 has been out since
more than two years, so IMO it is not asked too much to ask people who
want to use the latest and greatest version of ewoms to upgrade their
Dune.
the changes enable the storage cache and the intensive quantity cache
for all simulators of the lens problem and automatic differentiation
for the one which uses the ECFV discretization.
while the performance improvements are not worthwhile for the problem
in its default incarnation (using automatic diffentiation even
slightly degrades performance), it speeds up linearization by about
30% if the grid exhibits 16 times as many elements (e.g. by passing
the --grid-global-refinements=2) parameter.
at least, they compile as far as eWoms is concerned. Some external
libraries (in particular everything which uses SuperLU) still have
issues.
Also, there seem to be issues with the precision that is achievable
by the Newton method when using float.
this is because the reference solution changes for newer versions of
dune-alugrid and one of the main purposes of the lens problem is to
allow comparison with Dumux relatively easily. (Dumux usese YaspGrid
for its version of the lens problem.)
dune-alugrid >= 2.4 changed the element ordering changed from
lexicographical ordering to one defined by a space filling curve. the
old reference solutions are still valid (and obtained if older
versions of dune-alugrid are used) and are thus retained.
- start with an initial "do nothing" episode of 100 days to get
hydrostatic conditions.
- after that, produce oil and inject water for 900 days. (thereafter
the reservoir will be empty.)
- make the problem work with element centered FV discretizations. this
requires to make the width of the injection/production areas at
least one cell wide. This is achieved by using the new "WellWidth"
property which specifies the with of wells as a factor of the total
domain width.
- make the problem work with fully compositional models. This implied
to calculate the full composition for the fluid states which specify
the initial condition and the thermodynamic state at the wells.
- add tests and reference solutions for any combination of the {ECFV,
VCFV} discretizations and the {black-oil, NCP} models.
- the residual now does not consider constraints anymore
- instead, the central place for constraints is the linearizer:
- it gets a constraintsMap() method which is analogous to residual()
but it stores (DOF index, constraints vector) pairs because
typically only very few DOFs need to be constraint.
- the newton method consults the linearizer's constraint map to update
the error and the current iterative solution. the primary variables
for constraint degrees of freedom are now directly copied from the
'Constraints' object to correctly handle pseudo primary variables.
- the abilility to specify partial constraints is removed, i.e., it is
no longer possible to constrain some equations/primary variables of
a degree of freedom without having to specify all of them. The
reason is that is AFAICS with partial constraint DOFs it is
impossible to specify the pseudo primary variables for models which
require them (PVS, black-oil).
because of this, the reference solution for the Navier-Stokes test
is updated. the test still oscillates like hell, but fixing this
would require to implement spatial discretizations that are either
better in general (e.g., DG methods) or adapted to Navier-Stokes
problems (e.g., staggered grid FV methods). since both of these are
currently quite low on my list of priorities, let's just accept the
osscillations for now.
the utility is now more verbose (it actually prints what it does or
does not do), the test converts the example ART file shipped with
eWoms, and finally the art2dgf utility is now not considered a "unit
test" anymore (instead, it is an application).
they are required because the element ordering of the latest
dune-alugrid has changed. (it now uses a space-filling curve instead
of lexicgraphic ordering.)
