so far, it is only a flag which prevents the cache from being
deleted. To warn the user about a potential infinite loop, a warning
is printed if this flag was specified and some compiler or some compiler
flags were set by the user. This idea was proposed by Roland Kaufmann.
this seems to be a bug in cmake 2.8.10.2: if the user sets the
CMAKE_CXX_COMPILER variable for a build directory where this variable
has already been set, one gets an endless loop. This stings especially
if using the dunecontrol compatibility layer as the compiler flags are
unconditionally set via the CXX_FLAGS environment variable in the
options file. Running duncontrol on a module twice will thus trigger the
infinite loop if some compiler flags are set by the user.
The solution is relatively simple: Delete the CMakeFiles directory
before calling cmake. for the dunecontrol compatibility mode, we do
this in the configure script. For details about the cmake bug, see
http://www.cmake.org/Bug/view.php?id=14119
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
This should fix the common case where the curve is non-constant within
an intervall. I'm not really sure whether it's correct in all corner
cases, though.
this fixes the eWoms test case for the blackoil model which failed in
debug mode due to some asserts incorrectly triggering...
the only reason dune-istl was required was that the spline class used
ISTL's tridiagonal matrix. Since the spline class moved into the core
(along with a more capable tridiagonal matrix), ISTL is no longer
required by opm-material.
make all non-implementation headers includable without
preconditions. Also, this removes the GravityColumnSolver.hpp file,
because it tried to include a non-existing file and it was thus unused.
this is required to use the exception code of opm-core in
opm-material. Also, the Dune prerequisites of opm-material can be
removed once PR #345 is merged into opm-core...
this class can do both, more and less than dune-istl's BTDMatrix. more
because it supports entries on the lower left and upper right, less
because it does not support a block structure. The primary motivation
for this class were the spline classes which for which the former
feature is required to implement periodic splines and the latter is
not necessary...
This works pretty much the same way as DUNE_DEPRECATED (without message).
Thanks to Elias Pipping for implementing this.
dune-common SVN revision: r6556
for some of these files this is needed to make to keep it compiling
after the next patch because the new ErrorMacros.hpp file will no
longer implicitly includes <iostream>. for the remaining files it is
just good style.
While at it, the includes for most of these files have been ordered in
order of decreasing abstraction level.
for me, it was completely broken. (it worked fine if you did not want
to use it, though.) Now it (hopefully) follows the standard OPM
variable naming conventions, allows to use the internal SuperLU BLAS
library, and works fine if superLU is not installed on a system-wide
basis.
v2: cache the POST_2005 variable to make writing it to config.h more
reliable (on my kubuntu 13.04 system it did not work without it)
v3: re-add a proper "post 2005" check from newer versions of the dune tests
v2: incorporate Roland's nitpicks (I hope)
v3: It was decided that it's better to change the default behavior
v4: make sure the CMake syntax is correct even if the value of the
variable contains spaces (if it contains double quotes it's a
different matter, but that's pretty much a corner case, IMHO)
v5: properly escape backslash and double quote characters in the cmake
syntax
Seems like I forgot to include the "CheckCSourceCompiles" macro before
using it. Since it worked for me before, I'm wondering what made this
happen. Anyway, it should now work correctly in all cases.
ALUGrid is needed to avoid unresolved symbols if dune-grid was
compiled with it. METIS is used by the parallel version of
ALUGrid. (Although it is not open source...)
our policy is that we only use boost if necessary, i.e., if the oldest
supported compiler does not support a given feature but boost
does. since we recently switched to GCC 4.4 or newer, std::shared_ptr
is available unconditionally.
that one was due to the fact that the constructor arguments were no
longer used to initialize (unused) private member variables. These
warnings did not appear in CLang for some reason. Again, thanks to
Bård Skaflestad for the review.
'work' is a small, constant size array for temporary data so it can be
allocated on the stack and the 'work' parameter can be eliminated entirely.
Thanks to Bård Skaflestad for the suggestion!
most of them quite insignificant, but still annoying. The only
exception is the warning about the changed alignment for the 'work'
argument of spu_implicit_assemble(). AFAICT, the only reason why it
worked was that the pointer produced by malloc() was passed
directly. (malloc() seems to fulfill all alignment criteria.) To fix
this, I've changed that argument's type from char* to double*.
This allows projects which use the DUNE build system and want to use
OPM-Core to specify a dependency in their dune.module file. (i.e. they
don't have to worry about compiler and linker flags anymore.)
opm-core can still be used without having DUNE installed, though. This
means that for users which do not need/want a dependency on DUNE,
nothing changes.
v2: avoid naming conflict of the AX_BOOST_BASE macro with dune-common
by renaming it to OPM_BOOST_BASE.
v3: make the library detection work nicely
v4: Use AX_BOOST_BASE M4 macro from opm-core instead from dune-common
as base for OPM_BOOST_BASE to get rid of a few bugs, reworded
commit message. Thanks to Bård Skaflestad for the review.
This allows projects which use the DUNE build system and want to use
OPM-Core to specify a dependency in their dune.module file. (i.e. they
don't have to worry about compiler and linker flags anymore.)
opm-core can still be used without having DUNE installed, though. This
means that for users which do not need/want a dependency on DUNE,
nothing changes.
v2: avoid naming conflict of the AX_BOOST_BASE macro with dune-common
by renaming it to OPM_BOOST_BASE.
v3: make the library detection work nicely
v4: Use AX_BOOST_BASE M4 macro from opm-core instead from dune-common
as base for OPM_BOOST_BASE to get rid of a few bugs, reworded
commit message. Thanks to Bård Skaflestad for the review.
Andreas Lauser