This is a change from taking a vector containing the mapping to
deck-consistent logical cartesian indices. The mapping is contained
in the UnstructuredGrid::global_cell member, and may be null. The
change therefore saves the overhead of constructing a vector as a
copy of the data in the grid or (if null) as an identity mapping.
Now we may have a grid generated from deck input using the
keywords DXV, DYV, DZV, which will have a null pointer for
the global_cell mapping. We check if this pointer is null,
and create an identity mapping in this case. The mapping is
needed by the *PropertiesFromDeck classes (and helpers).
Apparently, Automakes prior to 1.10 do not automatically substitute
the absolute path directory variables
abs_srcdir abs_top_srcdir
abs_builddir abs_top_builddir
that Autoconf computes (since ca. 2003) into the Makefiles. This
leads to a subtle error when OPM-Core is used in conjunction with
dune-common's DUNE_CHECK_MODULES (or, more appropriately, our own
OPM_CORE_CHECK_MODULES) macro that gets invoked through dunecontrol.
The *_CHECK_MOUDLES macro contains an unconditional statement that
uses 'abs_top_srcdir' to compute the absolute path to the current
module's top source directory. When abs_top_srcdir is unset, the
root becomes unset too, whence the subsequent existence and validity
checks fail due to incorrect CPPFLAGS and/or LDFLAGS. It will also
fail to locate the 'dune.module' dependency file.
By explicitly substituting the above variables into the Makefiles,
as was also done in revisions 5819 and 5845 of dune-common's
Subversion repository, we're guarding against this particular
failure mode.
Tested on: CentOS 5.8 (Autoconf 2.59, Automake 1.9.6)
This is, at best, a work-around for an issue that presents when
earlier versions of Autoconf (e.g., 2.59) are used to process Dune's
DUNE_BOOST_BASE macro (introduced in dune-common@6480,
dune-istl@1492). For reasons I've been unable to determine, the
HAVE_BOOST symbol just gets #define-d, not set to `ENABLE_BOOST' as
was intended. Some kind of race condition?
Anyway, the Dune ISTL module uses statements such as
#if HAVE_BOOST
/* ... */
#endif
to determine if particular software features should be enabled.
This breaks down if `HAVE_BOOST' is simply defined. Following
commit fb614100, the symbol `OPM_HAVE_BOOST' is always defined (as a
Boolean state), so if we override ISTL's notion of `HAVE_BOOST', the
above construction continues to work.
We will, however, happily remove thise kluge if a better solution
arises in the core Dune modules.
This way, there will be no compiler warnings if the symbol is used
in a way akin to
#if OPM_HAVE_BOOST
/* Boost is available */
#else
/* Boost is not available */
#endif
We failed to propagate the BOOST_\(.*\)FLAGS -> OPM_BOOST_\1FLAGS fix
(commit 6b57a00) to all clients, notably our own macro for recognising
whether or not the Boost.Test library should be linked dynamically or
statically. This commit remedies that oversight.
Fix a misunderstanding that's been present since the inception. The
LDFLAGS variable is entirely at the builder's disposal. Flags needed
for system-internal settings must go in the AM_* equivalents.
This is an experiment, not strictly sanctioned by the AX_LAPACK macro
documentation, to avoid linker errors related to missing symbol MAIN__
in the (GFortran) run-time support libraries. Strictly speaking, we
should be using the method outlined in the Autoconf manual, but we'll
try the easier way for now.
This commit is more or less equivalent to forward-porting commits
dd6e0fd3, c437eba2, and 9e885dc7 from the "ert" branch.
When OPM-Core is used as a Dune module (e.g., as enabled by commit
789bc5ca7), we stand the risk of creating multiple, conflicting
defintions of crucial <config.h> symbols (e.g. `HAVE_BOOST') and
build variables (e.g., `BOOST_CPPFLAGS' and `BOOST_LDFLAG').
Avoid this situation by prefixing these symbols with an `OPM_'
string such that Dune's `ENABLE_BOOST' solution works as intendend
in modules that are derived in the OPM context.
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.
We do not want to distribute the AGMG sources along with OPM-Core.
These sources must be defined by the builder at configure time.
This fixes "make distcheck".
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.
