In the Wells struct, production rate control targets must be negative
(and injection rate control targets are always positive).
In the WellsGroup classes, there are separate variables for injection
and production, and all rates are positive. Therefore, upon adding or
modification of a production rate control, the negated value must
be used.
Update README with info about building opm-core as a dune module
Thanks, it clarifies the build options. I can try to improve further on it if I find time. However, I am afraid contract work will consume me in the coming weeks.
While libopmcore, following commit 37e14f, depends on (and references)
Boost.Filesystem (through the $(BOOST_FILESYSTEM_LIB) macro) this
indirect dependency is not sufficient to satisfy the requirements of
targets that use the indirect libraries directly.
Additional details at
https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
This installs a measure of safety on the part of the interface in that
the caller is free to dispose of the wells object upon returning from
the WellsManager constructor.
Disabled by default, this statement attempted to pass a std::istream to
function std::fclose() which is meaningless and should not be enabled at
any time--even for a MATLAB-related build.
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.
