to create a constant, there are now always the three functions
Opm::constant<Eval>(value);
Opm::constant<Eval>(numDeriv, value);
Opm::constant<Eval>(x, value); // with 'x' being the 'template' of the returned value
If a given call does not make sense, an exception is thrown:
- Plain floating point objects like `float`, `double` or `quad`
complain if the specified number of derivatives is not zero.
- Statically sized evaluations throw if the specified number of
derivatives of passed to the function is not equal to their static
size.
- Dynamically sized evaluations complain if the number of derivatives
cannot be determined.
The third variant of `Opm::constant()` works unconditionally. The
`Opm::variable()` helpers are modified analogously.
this creates an uninitialized "compatible" evaluation that is
compatible with its argument. For primitive floating point types and
statically-sized Evaluations, this is identical to calling the default
constructor, for dynamically sized ones, it creates an uninitialized
Evaluation object of identical size as the argument.
thanks to [at]GitPaen for the heads up.
e.g., looping over the wrong range or an infinite loop. also, the
dense-AD unit test is shortend to test one specialization and the
unspecialized class.
older compilers (-> GCC < 5) seem to have trouble with inlining here
which leads to sub-optimal performance. since it is not a big problem
to also generate the unspecialized Evaluation class, let's do that
instead. (for hand-written code, this would be a huge
consistency/maintainance problem, though.)
this allows the test suite of eWoms to be compiled on clang++ 3.8
using the following warning 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
```
without triggering warnings in opm-material or eWoms.
Note that the test-suite for opm-material does *not* yet pass without
warnings with these flags because with these flags clang likes to
complain about reducing or increasing floating point precision which
results in a formidable nightmare. I will see what I can do about
these warnings in a separate PR.
v4: properly fix the unused parameter warnings for the valgrind client
requests. thanks to [at]atgeirr for finding the issue.
this allows some flexibility of how an Evaluation object is
represented internally. the main motivation for this is to allow using
SIMD instruction which expect special data types as their operants.
for primitive floating point objects, these correspond to
std::isfinite() and std::isnan() while for evaluations, they trigger
on the evaluation's value or any of its derivatives being non-finite
or NaN. (i.e., for evaluations they should be better called
containsnonfinite(), containsnan().)
if this is not done the generic code produces NaNs. (either by using
the result of ln(0.0) or by means of a division by zero.)
This seems to fix the linearization of flow_ebos for "Model 2".
