"old" == "gcc 4.4". the standard c++ library of this compiler seems to
invoke the copy operator when creating objects in a vector, whereas
newer versions of the library don't. The problem is that std::unique
pointer cannot be copied because it is -- err -- unique and thus the
implicit copy operator for the SatFuncMultiplexer class gets deleted
by the compiler.
the fix is to introduce a "fake" copy operator which does not do
anything but is present to make std::vector of stdlibc++-4.4
happy. this is obviously not very elegant, but I could not come up
with a better solution. (another fix would be to use raw pointers
instead of std::unique_ptr, but IMO this does not qualify as
"better".)
basically, we now store a pointer to the base class and convert this
to the concrete incarnation of the saturation function. the only
disadvantage of this is that it requires to allocate the concrete
objects dynamically, i.e., there's another layer of indirection. On
the plus side it saves a few bytes per object and it makes things
quite a bit simpler, so it is a win IMO.
thanks to [at]atgeirr for suggesting this.
this makes it possible to switch to different saturation functions
again. So far the only supported function besides the default one is
the one which implements the "Stone 2" model.
this means the following changes:
- the "SatFuncGwseg" class is converted
- for now, Gwseg is the only saturation function supported by
SaturationPropsFromDeck. (will be changed in later commits.)
- the funcForCell() method of SaturationPropsFromDeck is removed as it
just occludes things
in any reasonable simulator which reads an ECL deck the deck is going
to decide which saturation function is to be used and not the outside
code. also, the table this which function will be using is not really the
calling code's business. (for any reasonable deck it is always going to
be a non-uniform table so it makes a lot of sense to avoid unnecessary
complexity IMO.)
this patch temporarily removes the ability to use anything except the
ECL default saturation function ("Gwseg"). this ability will be
restored later in this patch series.
instead, we will be going with wrapper classes around the PvtInterface
in the next commits. this considerably reduces the amount of
copy-and-paste required for temperature support.
this is implemented such that if the simulation is unchanged,
viscosities are assumed to be not temperature dependent. (only if
pvtObject->set{Oil,Wat}visctTables() is called, temperature dependence
is considered.)
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
Using "simple", the Norne deck aborts with an exception.
Note: SPE1 and SPE9 still seem to work fine with this but there might
be small differences so that the reference solutions of the Jenkins
server might need to be updated...
Atgeirr Flø Rasmussen
Andreas Lauser
Tor Harald Sandve
Markus Blatt
osae
Kai Bao