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.
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.
`getValue(x)` should be better called `value(x)` but this leads to
really cryptic compiler errors which seem to be related to the fact
that the Evaluation class has a `value` attribute (this is for GCC
5.2.1).
with this, evaluation objects can be decayed via
`Opm::decay<Scalar>(x)`. since function templates do not require a
'template' qualifier, it is a bigger advantage for this function that
for the mathematical ones. (the conventional way to do this is way
more verbose:
```c++
Opm::MathToolbox<Evaluation>::template decay<Scalar>(x)
```
)
this PR was inspired by one of @atgeirr's recent comments. it allows
to get rid if the `MathToolbox<Eval>` detour for the dense AD code in
most cases: e.g. instead of writing
```c++
template <class Eval>
Eval f(const Eval& val)
{ return Opm::MathToolbox<Eval>::sqrt(val); }
```
one can simply write
```c++
template <class Eval>
Eval f(const Eval& val)
{ return Opm::sqrt(val); }
```
and it will work transparently with DenseAD `Evaluation` objects and
primitive floating point values.
one complication of this is that the type of the `Evaluation` object
does not need to be explicitly defined. for functions which take more
than one argument (like e.g. `pow()`, `min()` and `max()`), it is thus
assumed that the type of the result is the same as the type of the
first argument.
another drawback is that when both, the contents of the `Opm::` and
the `std::` namespaces are implicitly available, it is not clear to me
what's used for primitive floating point values. (it seems to compile
but IMO it could lead to surprising behaviour. thus, please only merge
if you consider the benefits of these convenience functions to be
greater than their drawbacks.)
also, only calculate a factor if the currently observed oil saturation
is smaller than the maximum oil saturation. The new code is not
completely equivalent to the old one because derivatives are not
considered if the oil saturation increases, but the differences should
be small and they should be closer to how the current master version
of opm-simulators handles VAPPARS.
this is yet another crazy Eclipse hack: it prevents the dissolved
component to be fully assimilated by solvent phases if the maximum oil
phase saturation seen during the simulation stays below a given
limit...
Since "dense automatic differentiation" describes what this code is
all about much better in my opinion. ("Local AD" is just a possible
use case in the context of PDE discretization.)
these warnings were caused by the fmatrix.hh header being included
before Evaluation.hpp. While they were harmeless, they were annoying.
(I did not discover this earlier because I normally use Dune 2.4 which
does not have this particular issue.)
so far, they only printed a warning. in this case the error message
was usually ignored and the test was counted as 'passed'. (before the
switch of the flash solvers to use automatic differentiation, this
happened in some cases where single precision floating point scalars
were used.)
not anymore: now an exception is thrown and the test is aborted if an
error is detected.
In my recent experience it did more harm than good: tags often made
the compiler errors mucht longer and more unreadable, and I have not
encountered a single instance where they were really helpful...
so far, using function evaluation objects instead of primitive
floating point scalars only worked for trivial parameter caches which
do not store any values (most of the time, this means that the
ParameterCache is `NullParameterCache`), or it explicitly did not work
(like for `Spe5ParameterCache`). this patch fixes the problem by
making the parameter caches of fluid systems template classes which
are templated on the type of scalar values. On the flipside, this
requires changes to all downstream modules that use fluid systems.
this patch removes the in-file lists in favor of a global list of in
the COPYING file. this is done because (a) maintaining a list of
authors at the beginning of each source file is a major pain in the
a**, (b) for this reason, 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 replacing the lists...)
opm-parser#677 changes the return types for the Deck family of classes.
This patch fixes all broken code from that patch set.
https://github.com/OPM/opm-parser/pull/677
this makes things go less in circles: before this patch, the
interpolation happened on the inverse formation volume factors, the
PVT classes inverted the result to get the FVF and then the calling
code divided by what fell out of this. Now, the calling code can
directly multiply with the result of the interpolation.
for some unit tests the precision of `float` is insufficient. To at
least enforce that the tested code compiles with `float` as Scalar,
they are wrapped by `while(false)` statements.
hopefully this fixes all of them. While doing this, I noticed that the
warnings produced by GCC 5 and GCC 4.9 differ. I did not try to
compile it with GCC 5, though.
i.e., the PVT region index is passed directly to them and the
ParameterCache objects are not required. also:
- convert all methods to fluid states instead of passing the dependent
parameters directly.
- do no longer encode the phase or component names in the method names
of the fluid system.
- they are not concerned with fugacity anymore:
- as a consequence, they are now more self contained:
- they do not need to know the molar mass of each component anymore
- they do not need to call methods of the other PVT classes
anymore (that was only needed to be able to calculate the
fugacity coefficients consistently.)
- quite a few methods could be removed
- also, some methods where renamed for consistency.
