this is only relevant people who are masochistic enough to go beyond
`-Wall`. (note that at this warning level, there is plenty of noise from
Dune and other upstream dependencies.)
further, this cleans up the code of the parameter system and the
startup routines a bit and finally, it adds positional parameters
support to ebos as well as brief descriptions to ebos and the lens
problem.
Dune::set_singularity_limit() was removed and the ILU preconditioners
seem to have been refactored. The ILU refactoring included making the
order of the preconditioner a template parameter of the preconditioner
class, i.e., it can no longer be specified at runtime.
Note that the AMG code in the dune master currently produces quite a
few warnings because of the latter point, but as far as I can see,
there is nothing which can be done about this from outside of
dune-istl.
IMO the term "vanguard" expresses better what these classes are
supposed to do: level the ground for the cavalry. Normally this simply
means to create and distribute a grid object, but it can become quite
a bit more complicated, as exemplified by the vanguard classes of
ebos..
instead of passing a "minimal" fluid state that defines the
thermodynamic conditions on the domain boundary and the models
calculating everything they need based on this, it is now assumed that
all quantities needed by the code that computes the boundary fluxes
are defined. This simplifies the boundary flux computation code, it
allows to get rid of the `paramCache` argument for these methods and
to potentially speed things up because quantities do not get
re-calculated unconditionally.
on the flipside, this requires slightly more effort to define the
conditions at the boundary on the problem level and it makes it less
obvious which quantities are actually used. That said, one now has the
freedom to shoot oneself into the foot more easily when specifying
boundary conditions and also tools like valgrind or ASAN will normally
complain about undefined quantities if this happens.
according to wikipedia the term "heat" is the energy transferred due
to a temperature gradient, i.e., it only makes sense if such a
gradient is present and this is not necessary for the storage term.
this means that technically the term "heat conductivity" is
meaningful, but "thermal conductivity" is IMO more consistent.
this has partially already been done in opm-material and eWoms it was
pretty inconsistent, so it also requires a patch in opm-material.
it broke because of the recent refactoring of the energy material laws
in opm-material. The reason why nobody noticed is that this test
requires dune-alugrid to be compiled.
there seems to be only a *very* limited amount of interest, the code
of the model is quite complex and there are currently no suitable
discretizations for free-flow equations in eWoms (i.e., the model
tends to be very unstable and oscillates a lot). Combined, all of this
makes maintaining this model a pain in the back, so let's remove it
some interest in these kinds of problems surfaces and until
appropriate discretizations -- like staggered grid methods -- are
available.
This works by having a "focus degree of freedom" during
linearization. When evaluating the local residual, all derivatives of
the residual/fluxes are with regard to the primary variables of that
DOF.
The two main offenders were the Forchheimer velocity model and the
model for the Stokes equations. To ensure that they continue to work,
the "powerinjection" and the "stokestest2c" problems are now both
compiled and tested with both, automatic differentiation and finite
differences, and the results of these tests is compared against the
same reference solution.
The majority of the time required to develop this patch was actually
required for testing: All tests compile and pass with debugging and
aggressive optimization flags with at least GCC 5, GCC 7 and clang
3.8, as well as Dune 2.3 and 2.4. Also, the results of flow_ebos stay
identical for Norne whilst the performance difference is below the
measurement noise on my machine. (the version with this patch applied
was actually about 1% faster.)
the groundwater problem should be symmetric because it uses an
incompressible fluid, is a single phase problem and uses the
immiscible model. (i.e., there should never be a difference between
the upstream and the downstream cells.)
the main purpose of this commit is to have a test that uses a linear
solver wrapper which was generated by the internal
EWOMS_WRAP_ISTL_SOLVER macro.
... and use the restarted GMRES solver in conjunction with a ILU-2
preconditioner for the water-air unit test.
I do not really recommend using these solvers because BiCGSTAB tends
to be 20% to 30% slower than our home-brewn implementation (this is
because the dune-istl solvers cannot use custom convergence criteria),
but dune-istl offers more choices than just BiCGStab and this
functionallity could be helpful when debugging issues related to
solving the linear systems of equations.
Note that regardless of how pedantic the interpretation of DUNE's
license is, there are no licensing issues with this code because we do
not distribute any files derived from DUNE anymore.
i.e., the solvers.hh file is removed. The main reason for this is that
it avoids having to distribute a file with a potentially incompatible
license (i.e., GPLv2 + template exception vs GPLv2+), but the
home-brewn bicgstab solver also seems to perform a tiny bit better.
i.e., using clang 3.8 to compile the test suite with the following
flags:
```
-Weverything
-Wno-documentation
-Wno-documentation-unknown-command
-Wno-c++98-compat
-Wno-c++98-compat-pedantic
-Wno-undef
-Wno-padded
-Wno-global-constructors
-Wno-exit-time-destructors
-Wno-weak-vtables
-Wno-float-equal
```
should not produce any warnings anymore. In my opinion the only flag
which would produce beneficial warnings is -Wdocumentation. This has
not been fixed in this patch because writing documentation is left for
another day (or, more likely, year).
note that this patch consists of a heavy dose of the OPM_UNUSED macro
and plenty of static_casts (to fix signedness issues). Fixing the
singedness issues were quite a nightmare and the fact that the Dune
API is quite inconsistent in that regard was not exactly helpful. :/
Finally this patch includes quite a few formatting changes (e.g., all
occurences of 'T &t' should be changed to `T& t`) and some fixes for
minor issues which I've found during the excercise.
I've made sure that all unit tests the test suite still pass
successfully and I've made sure that flow_ebos still works for Norne
and that it did not regress w.r.t. performance.
(Note that this patch does not fix compiler warnings triggered `ebos`
and `flow_ebos` but only those caused by the basic infrastructure or
the unit tests.)
v2: fix the warnings that occur if the dune-localfunctions module is
not available. thanks to [at]atgeirr for testing.
v3: fix dune 2.3 build issue
10^-4 lead to sporadic results if the final tolerance of the solution
really was 10^-4. (it currently is usually better because each time
step experiences an additional update after the Newton method deems it
to be converged.)
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.
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...
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.))
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.)
