since the unit code within opm-parser is now a drop-in replacement,
this simplifies things and make them less error-prone.
unfortunately, this requires quite a few PRs. (most are pretty
trivial, though.)
Have removed the SimulatorState base class, and instead replaced with
the SimulationDatacontainer class from opm-common. The SimulatorState
objects were typcially created with a default constructor, and then
explicitly initialized with a SimulatorState::init() method. For the
SimulationDataContainer RAII is employed; the init( ) has been removed -
and there is no default constructor.
1. Added method setCellDataComponent()
2. Removed setFirstSat()
Implemented saturation initialisation using setCellDataComponent()
instead of setFirstSat(). This way the template<class Props> has been
removed from the SimulatorState class.
This PR adds allow_cf to the wells structure that determine whether
crossflow is allowed or not. An extra argument is added to addWell(..)
to specify the allow_cf flag.
our policy is that we only use boost if necessary, i.e., if the oldest
supported compiler does not support a given feature but boost
does. since we recently switched to GCC 4.4 or newer, std::shared_ptr
is available unconditionally.
Mostly one would assume that this would be the porosity since that's the
only non-named argument, but stating this explicitly saves us from one
trip to the manual.
Since the data files are generated by the tutorials, it is natural to
have the figure generation program also together with this source code;
otherwise people may think that it have to be used for *all* figures
The existing description did not properly account for ERT (or, more
appropriately, the "libecl" part of ERT) being installed in a
non-default location (e.g., somewhere below ${HOME}).
As EclipseGridParser.hpp declares various ERT-dependent types and
functions if a build configuration supports ERT (activated by the
`--with-ert' configure option), we need a proper include path to
reference the ERT headers. The fix is simple--just insert the
$(ERT_CPPFLAGS) into the already existing $(AM_CPPFLAGS).
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.
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.
