This resulted in _quadratic_ complexity if data points where retrieved
one-by-one. For the Norne case, this had the consequence that
retrieving the data for ZCORN (-> about 1M data points) took hours...
now the data is parsed from a string specified in the source file
instead of a separate file, the PvtgTable utility class is tested and
the order of the fields in the JSON definition of PVTG is the same as
for that of PVTO.
detecting empty records is still pretty hacky: When calculating the
number of flat items, we stop at the first item for which the default
was applied.
Also, this patch corrects the names of the columes used by the PVTG
keyword. (the first column is pressure, then comes Rv.)
these are convenient to convert everything required to rip out the old
parser of sim_fibo_ad. the concrete keywords are:
- COMPDAT
- EQUIL
- GCONINJE
- GCONPROD
- GRUPTREE
- WCONINJE
- WCONINJ
- WCONPROD
- WELOPEN
- WELSPECS
- WGRUPCON
in the medium term it would be nice if these wrapper classes could be
automatically generated from the JSON keyword descriptions.
the motivation for this is the 'TSTEP' eclipse keyword.
the reason why this dimension is not simply called 'Time' is that in
eclipse, different keywords might use different units, e.g. one
keyword could use seconds, another could use years while a third uses
days. As an added bonus, the used time units may be different for
different scales but identical in others (e.g., for one keyword times
might be specified in 'days' for the metric as well as for the
labscale, but in 'days' and 'hours' for another second keyword.)
as it was decided that having editor-specific stuff in files is not
wanted in OPM. for emacs, a .dir-locals.el file is added to the
module's root directory which should have the same effect.
the idea is to create a lightweight wrapper objects around
DeckKeywords which allow more convenient and more readable access to
the data. E.g. instead of
std::vector outerColumnNames{"RV", "P", "BG", "MUG"};
std::vector innerColumnNames{"P", "BG", "MUG"};
Opm::FullTable pvtgTable(deck->getKeyword("PVTG"),
outerColumnNames, innerColumnNames);
pvtgTable->getOuterTable()->getColumn(1);
one now better uses
Opm::PvtgTable pvtgTable(deck->getKeyword("PVTG"));
pvtgTable->getOuterTable()->getPressureColumn();
the idea for the other keywords is similar.
This is intended for keywords like SWOF which currently is a big
vector of doubles but one needs to use the data in a column oriented
way.
This class is intended to be used like this:
Opm::DeckKeywordConstPtr swofKeyword = newParserDeck->getKeyword("SWOF");
Opm::SimpleTable swofTable(swofKeyword,
/*columns=*/std::vector<std::string>{"SW", "KRW", "KROW", "PCOW"},
/*recordIdx=*/table_num);
const std::vector<double>& sw = swofTable.getColumn(0);
// ...
what might be useful is to move the column names into the JSON
description of the keywords, but I could not find a way to go back to
the parser from the deck/keyword. maybe this is not even desireable as
decks might also be created by other means...
Also, a multi-record variant of the class is available. That one is
intended for keywords like PVTO where the first few items of each
record form a table (in the case of PVTO: Rs, pressure, Bo, and
viscosity for staturated oil) and the next entries constitute another
table (in the case of PVTO: pressure, Bo and viscosity for
undersaturated oil with the same RS factor as the first entry).
The second kind of tables can be constructed using the item-based
variant of SimpleTable.
Parser::parseData is quite useful for unit tests to prevent them
spilling files to everything. Also, what was formerly
Parser::parseFile has been renamed to Parser::parseStream and slightly
modified to not be specific for std::ifstream.
