... because every 2D function depends on two variables which are
usually called X and Y. The name of that class is still clunky,
suggestions are appreciated.
(also, UniformXTabulated2DFunction is a bad name. I also take
suggestions for that.)
this has mildly annoyed me for quite some time, and finally managed to
bring myself to changing it: The Opm::FluidSystems namespace is pretty
useless because the number of classes contained within it is quite
small and mismatch between the naming convention of the file names the
actual classes is somewhat confusing IMO. Thus, this patch changes the
naming of fluid systems from `Opm::FluidSystems::Foo` to
`Opm::FooFluidSystem`.
(also, flat hierarchies currently seem to be popular with the cool
people!?)
this patch requires some simple mop-ups for `ewoms` and `opm-simulators`.
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.
this was only partially done so far: the term "heat" should be avoided
if possible because it is a somewhat fuzzy concept. Thus, replace it
by "energy" and "thermal" where it is not a well established
term. ("well established" basically means "heat capacity".)
thermal laws are the heat conduction laws plus "solid energy laws"
which can be used to specify the relations which govern the volumetric
internal energy of the solid matrix of the porous medium.
this flag is way too non-descript (a complex relation for one person
may be a simple one for another), the implementation is pretty
inconsistent and it makes the code more complicated and harder to
maintain. Thus, IMO the approach turned out to be a bummer, so let's
pull the plug.
this patch converts to code to use the convenience functions instead
of the math toolboxes whereever possible. the main advantage is that
Opm::foo(x) will work regardless of the type of `x`, but it also
reduces visual clutter.
also, constant Evaluations are now directly created by assigning
Scalars, which removes further visual noise.
while I hope it improves the readability of the code,
functionality-wise this patch should not change anything.
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.)
