If we restart from a later time, then the SimulatorTimer should be
restarted in that state as well, so it is already always a reflection
of how far we've progressed in the input file's schedule.
The EclipseKeyword class takes care of cleaning up the handle after we
are done using it, and provides several convenience constructors that
make the code read easier.
If the package suite was given (e.g. DUNE_ROOT=/blum), then the code
set up the root for each individual package automatically (e.g.
DUNE_COMMON_ROOT=/blum/dune-common), but the path which was then
activated did not get the local build sub-directory (e.g. if we are
building opm-autodiff in /frub/opm-autodiff/build, then the local
build directory is "build/"), and thus this was not appended to the
library search path. The result was that the source was found (because
the root pointed to a valid source tree), but the library was not
(because it is "hidden" in the subdirectory).
The code to condense the output using repeat counts was disabled
long ago (commit fc992da). If we ever need this feature, we can
bring it back from history or reimplemented in a refined fashion.
There is no need to use a nested loop to output a constant number of
items per line. We only need to output a '\n' rather than a ' '
after every "nl" item output.
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
