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 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 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.)
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...
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...)
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.
- add unit tests for the EclMaterialLawManager and the black-oil PVT classes
- rework the API of the blackoil PVT classes so that it follows the
initFromDeck() pattern and uses multiplexer classes instead of
dynamic polymorphism to select the concrete PVT approach
- the former change allowed to use the BlackOil fluid system with
arbitrary Evaluations, i.e., it is not limited to a single
Evaluation class which is specified as a class template argument
anymore.
- more fixes for GCC and clang warnings. now it should be reasonably
hard to trigger warnings using these compilers.
this commit squashes the following patches:
- add a unit test for the EclMaterialLawManager
- black oil: simplify the WaterPvtInterface
- add a unit test for the PVT classes of the black oil fluid system
- black oil: improvements to the PVT classes
- blackoil PVT: remove dynamic polymorphism
most of these people like to inflict pain on themselfs (i.e., warnings
in their own code), but they usually don't like if pain is inflicted
on them by others (i.e., warnings produced by external code which they
use). This patch should make these kinds of people happy. I'm not
really sure if the code is easier to understand with this, but at
least clang does not complain for most of the warnings of
"-Weverything" anymore.
it is called "simple" because the usage is somewhat simpler: The
quantities are stored and those which are not can be specified using
simple boolean template arguments instead of having to pass the class
names of the storage modules. The definition of the class is quite a
bit more involved than the non-"simple" variant, though.
in fact they wouldn't have needed any modification, but returning
constant references instead of copies of the stored values saves quite
a few calls to copy constructors.
besides this, fluid states are now required to export the 'Scalar'
type, which allows to use it outside of the FluidState without
resorting to the c++ 'decltype' construct.
they used to be in opm-core, but this allows to be more flexible with
the dependency order: What's now called "opm-core" can easily depend
on opm-material which might come in handy for the refactoring.
Besides moving in classes from opm-core, the infrastructural code
which was still in opm-material is moved to the directory
opm/material/common. The intention is to collect these classes at a
central location to make it easy to move them to a real "core" module.
(if this is ever going to happen.)
- the StaticTabulated2DFunction class and the base class
(Tabulated2DFunction) are gone
- the DynamicTabulated2DFunction class has been renamed to
UniformTabulated2DFunction
- a new class called UniformXTabulated2DFunction has been
introduced. Like UniformTabulated2DFunction, it assumes uniform
intervalls of the sampling points in X direction, but in contrast to
UniformTabulated2DFunction, the Y locations of the sampling points
can be set freely (as long as they are specified in increasing order
for each x value)
- add a unit test for the two tabulation classes
