It's not possible to have `constexpr std::string`s in C++17. Taking
`std::string_view` gives conversion errors. Since this is all temporary
and will be replaced by pure runtime parameters anyway, use string
literals for the moment.
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.
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.
... 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., 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
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 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 goal is to make it faster on computers with many cores: The
easiest way to do this is to ensure that the longest running tests are
not taking too much time and that they need about the same time. Thus
this patch contains the following changes which limits the CPU time
taken by each test to about two minutes in debug mode on my machine:
- the water-air problem using the non-isothermal primary variable
switching model now uses an 16x16 instead of a 32x32 grid. as a
compensation it now runs for a year instead of 5000 seconds and the
global grid refinement is now tested.
- the end time of the lens problem ctests is now 3000 instead of
30000 seconds. The binary itself does not change at all.
- sort the tests in the CMakeLists.txt roughly in the order of their
required time. (this will cause ctest not having to wait for long
running test which were started late for too long.)
this means that all code which could potentially throw an exception is
moved to this method(). (In particular FluidSystem::init() proved
troublesome in the past.) Besides avoiding segmentation the faults
which stem from exceptions thrown in constructors, this also has the
advantage that simulations which spend a noticable amount of time to
initialize stop at the "correct" place, i.e. after the "Finish init of
the problem" message was printed by the simulator...
"intensive" means that the value of these quantities at a given
spatial location does not depend on any value of the neighboring
intensive quantities. In contrast, "extensive" quantities depend in
the intensive quantities of the environment of the spatial location.
this change is necessary is because the previous nomenclature was very
specific to finite volume discretizations, but the models themselves
were already rather generic. (i.e., "volume variables" are the
intensive quantities of finite volume methods and "flux variables"
are the extensive ones.)
