10^100 cannot be represented by single-precision floating point values
and 10^30 is large enough considering the fact that the distance from
Earth to Alpha-Centauri is "only" about 4*10^16 m...
by default, this just checks if the saturation of the incriminating
phase is larger than 0, but in some cases (i.e., black-oil) the
calling code might have a different opinion: E.g., the black-oil model
looks at the primary variables to determine the phase presence.
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.)
mainly these issues stemmed from the fact that floating point values
can be negative and casting negative values to unsigned integers leads
to very large unsigned values instead of 0.
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.
IMO this is pretty cool because it allows to transparantly calculate
higher order derivatives. for example this enables to implement the
linearization stage of higher-order non-linear solvers without much
additional effort compared to just evaluating the function in
question. (essentially, such higher order non-linear solvers are based
on truncating the Taylor series not after the first term -- like for the
Newton scheme -- but later. That said, they require to solve linear
systems of equations which involve tensors of orders greater than 2,
so they are not really practical as far as I can see.)
A more practical motivation for this is to allow the constraint
solvers to be used in "nested mode", i.e., linearizing the system of
equations they need to solve using automatic differentiation, but
allowing the value objects which are passed to the constraint solvers
be function evaluations themselves. (E.g. the result of a flash
calculation can also include the derivatives with regard to the
primary variables of the flow model. Note that the individual
constraint solvers need to some patches to make this work.)
this method is an artifact from the beginning of the automatic
differentiation code and is not needed anymore: its original pupose
was to be able to retain a full function evaluation object if it was
available or a function evaluation object representing a constant
function if only a primitive scalar is available. Nowadays, the method
can be replaced by a direct initialization:
template <class T, class V>
T fn(const V& v)
{ return T(v); }
is equivalent to
template <class T, class V>
T fn(const V& v)
{
typedef Opm::MathToolbox<T> Toolbox;
return passThroughOrCreateConstant(v);
}
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...)
