I haven't figured out why this happens, but on one of my computers
running kubuntu 13.10 g++ says the following if one tries to use
quadruple precision math:
/home/erne/src/ewoms/ewoms/common/quad.hh: In static member function ‘static quad std::numeric_limits<__float128>::min()’:
/home/erne/src/ewoms/ewoms/common/quad.hh:52:14: error: unable to find numeric literal operator ‘operator"" Q’
{ return FLT128_MIN; }
since this happens only on this machine and only with the c++ (but
not the C) compiler, i suppose that this is either an upgrade issue
with kubuntu or an issue with the ubuntu gcc stack. Strangely enough,
my other kubuntu machine does not have a problem with that...
In any case also testing for assignability of constants and using the
C++ compiler for the quadmath test won't hurt...
also, extend the unit test for it. (*phew* that was much more fun than
appreciated because of all the index shifts. I'm still not 100% sure
that everything works in all corner cases, but at least my confidence
is at 95%.)
most of these issues are fallout from the conversion of the spline
class from a moments (second derivative) based approach to hermite
base functions:
- the second and third derivatives where incorrect, and the third
derivative was not available in the public interface.
- The unit test did not check the derivatives
- The coefficients for the monomial basis were off by the factors
stemming from the derivatives
- The intersectIntervall_() method used std::max() instead of
std::min() at one place and still added the base offset for the x
values as indicated by Stoer
Currently, it still writes out whatever conservation quantity which is
used by the solver (which is probably the mass of the oil/gas
mixture). TODO: convert these solver rates to "pure oil volume without
gas at the surface" and to "gas volume at the surface" rates.
thanks again to Joakim Hove for the pointers where to start kicking!
most code was shamelessly ripped from opm-core's EclipseGridParser,
but there are some additions (e.g. grids specified using the D[XYZ]V
Eclipse keywords can be used).
The code is located inside the new class "BlackoilEclipseOutputWriter"
(should probably renamed) and hooked up in
SimulatorFullyImplicitBlackoil and sim_fibo_ad.cc.
Also be aware that, to make this code work properly, the newest master
version of ERT is required (i.e. one which includes commit
5e4e9661720). In this context, I would like to thank Joakim Hove for
his support!
Some packages are split up in several library files, where each of them
doesn't have their own CMake find-module. So we cannot put this list in
the prerequisites. Unlike the headers, where we just add the directory,
all the libraries must be explicitly named on the link line. Thus, we
should allow to specify more than one name in the lib parameter.
The first name specified is designated as the "primary" library and is
assigned to the _LIBRARY variable; the others occur in _LIBRARIES as if
they were prerequisites.
Note that the build system cannot replicate this setup itself; it always
assumes that we are building (at most) one library from the source
files.
Some packages are split up in several library files, where each of them
doesn't have their own CMake find-module. So we cannot put this list in
the prerequisites. Unlike the headers, where we just add the directory,
all the libraries must be explicitly named on the link line. Thus, we
should allow to specify more than one name in the lib parameter.
The first name specified is designated as the "primary" library and is
assigned to the _LIBRARY variable; the others occur in _LIBRARIES as if
they were prerequisites.
Note that the build system cannot replicate this setup itself; it always
assumes that we are building (at most) one library from the source
files.
Since there are a few new APIs and features, but no major changes,
it seems proper to move from 1.0 to 1.1, even though strict
backward compatibility cannot be expected.
Label bumped to 2013.10.
The previous version assumed that we had libraries, and thus always
installs the .pc file in the multi-arch library directory. However,
we now have modules which does not have a library, but whose header
files still need to be located. Since the lib/ directory is usually
in the pkgconfig search path, it is natural to put them there.
If -DSUITESPARSE_USE_STATIC=ON, then the build system will only look for
static versions of the libraries that are part of SuiteSparse, even if
dynamic/shared versions are present on the system. Thus, the default of
preferring dynamic libraries can be overridden.
SuiteSparse is rarely built ourselves, but still uncommon enough to not
be present on computing clusters.
This patch allows us to install the libraries on a workstation, for
instance from package suitesparse-devel and link to it statically
without having to maintain our own build tree.
A vector can of course never contain a negative number of elements, so
naturally size() returns size_t instead of a regular int. This costs us
a warning unless we also change the loop counter (since it is only used
to index that vector).
