This commit shows a very basic example of how Logging singleton can be
implemented. The commit consists of a fully static class OpmLog which
manages a Logger class; in this case an instance of the ParserLog
class. The static OpmLog class can then be used from anywhere in the opm
code with:
OpmLog::addMessage( messageType , "Log message")
Before this can be really useful the Logger class should be extended /
subclassed / ... for general usability.
the intention of it is to specify the component index which should be
used to calculate the properties of the gas and oil phase in the case of
thermal black-oil runs. The keywords are supposed to use Eclipse-style
indices, i.e., "1" is stands for the first component.
The reason why I think that this is required at all is that I have not
found out if Eclipse does use temperature dependent gas viscosities
and densities for non-compositional runs. (I have found a few
equations in the RM and TD for gas which include temperature for
compositional runs on E300, though.)
Note that there won't be a WCOMPIDX because compositional simulations
in Eclipse do not seem to treat water as a separate component...
if somebody has a better idea or knows how eclipse does this for
thermal black-oil simulations, let me know...
strangely enough, [at]totto82 an me did not find a corresponding
keyword for the gas phase. Also, the documentation of the second item
of the WATDENT keyword seems to be incorrect to me because its default
in FIELD units it is off by a factor of 10^4 compared to the one for
METRIC (at least in my copy of the RM).
This is required for keywords which do not use "every-day" temperature
values but thermodynamic ones or keywords that use "per degree"
values. Examples of such specimen are the OILCOMPR and WATDENT
keywords.
Withe this commit the ParserRecord objects are created as needed by the
ParserKeyword; i.e a parserkeyword can in principle be totally without a
record.
Also, I tried to convert all keywords that use reservoir volumes and
the associated code. Although I tried my best on that front, it might
not be enough. (in any case, I consider it very unlikely that there
are any regressions caused by this.)
it turns out that, in contrast to the RATE item, this item is always a
liquid rate (-> bbl/day in FIELD units), i.e., the dimension is always
"LiquidVolume/Time" irrespectibly of the fluid phase.
quite a few important methods (e.g., getWells()) missed the variants
which are marked as 'const'. this leads to the problem that these
can't be called on the object returned by EclipseState::getSchedule()
because it returns a ScheduleConstPtr. (this issue can possibly be
worked-around by creating a new mutable copy of the schedule object
from the one returned by EclipseState::getSchedule(), but to me, this
seems to be strikingly inelegant and inefficient...)
this fixes the compilation of the ECL blackoil simulator of eWoms...
