Specifically, commit ff4f709e made the support for transitively
conveying interlibrary dependencies onto clients of OPM-Core more
robust. As a consequence, we no longer need to explicitly link in the
Boost.System or Boost.Filesystem libraries to use the software contained
therein.
Specifically, use the OPM_BOOST_LIBDIR variable created in commit
5c97e512 and Libtool's "-R" link-time switch to encode the library
location within OPM-Core's run-path. This simplifies using the library,
because the onus of satisfying the library's link-time requirements is
removed from the client.
A second refinement puts the additional link-requirements (i.e., "-l"
and "-L" options) within the *_LIBADD primary. This moves the libraries
from the middle to the end of the link statement.
middle.
This enables explicitly encoding the directory, e.g., in the OPM-Core
run-path. This, in turn, reduces the burden on library clients that
would otherwise have to satisfy library link requirements in addition to
any other link requirements they might have.
This change implements the approach of (e.g.,) ax_boost_system.m4, but
may lose some of the initial refinements. In that case, we will have to
refine this code.
The constant 6 is the number of array dimensions needed to successfully
allocate a grid. While unlikely, this number may change in the future
and it is better to have a manifest constant (in this case, GRID_NMETA)
than a hard-coded number.
There is little to no error checking, and the importer assumes that the
grid is serialised more or less directly from the grid structure.
Intended use: Testing on non-uniform grids created in MRST.
Changing transport source convention
Tested locally. No regressions. Merged.
Long-term, we may need to do away with scalar source terms though--at least for black-oil type problems.
Commit 642eaf6 introduced the correct documentation, but mixed the order
of the 'zcorn' and 'actnum' documentation. This commit corrects that
oversight.
Basis functions, quadratures and velocity interpolation are basic versions,
not handling any higher than DG(1) for now. These are currently in helper
classes and functions. The code in the main solver class is written with
the aim of supporting DG(n) generally.
