This computes pressure differences with respect to the bottom-hole pressure
for each well perforation, based on the well flows. It is explicit and not
implicit, using the previous time step's flow rates to calculate the necessary
densities.
I'm neither sure that this is fully correct nor that I found all
occurences (so far, the output writing code is missing in this patch),
but it seems to work for SPE1...
Commit 4aa0eaf introduced density and viscosity evaluators into the
BlackoilPropsAdInterface that accepted an externally assignable
condition to distinguish saturated from unsaturated cases. As a
result of a few low-level technical problems with that approach,
this commit changes those affected interfaces to use the black-oil
specific 'PhasePresence' facility of opm-core's commit a033329.
Update callers accordingly.
The criteria for whether the fluid is saturated or not is moved from the
within the pvt calculations to the solver, and passed to the pvt
calculations as a array of boolean values.
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).
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...
The most severe change probably is the removal of the AutoDiff
debugging helper functions which were useful from within a debugger
but unfortunately had to rely on a presumed linker bug in order not to
be removed in the final binary.
Also, some private attributes were unused. These have been removed and
the constructors of their respective classes have been adapted. Once
their intended functionality is actually implemented, they should be
brought back on an as-needed basis.
Thanks to @bska for the review!
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.
