By representing string_view as char* instead of
std::string::const_iterator the string_view class bring possibly
slightly lower overhead, but mostly enables some optimisations.
A simple non-mutating view into a string. Implements a shallow reference
to a std::string, replicating its operations to be drop-in replaceable.
Primarily designed for inner loop use, where expensive string
allocations become a performance killer.
Utility/Functional is a lightweight high level functional-oriented sub
library that attempts to abstract some common uses and boilerplate
around the parser code (and later maybe for other modules to use).
This patch introduce only three functions, but they have proven common
enough to warrant some common implementation.
Since the Deck* family of classes have changed their interfaces to no
longer use shared_ptr, a lot of code broke. This patch fixes all
problems in tests, other signatures and accesses to now use the new Deck
interfaces.
Every header is self-contained and includes only what it must to
function, relying on users include what they need in source files,
adopting a pay-what-you-use model (in particular for internal
dependencies).
This is an effort to improve build performance. Several includes
scattered across the project are either unused or partially used (i.e.
just used to import a type name, not depending on the actual contents of
the header file).
Replaces a lot of these includes with forward declarations.
since tables can be tricky, we now enforce that the compiler bails out
if the user tries to instantiate a table class manually.
Note that a bit of trickery is needed to keep the low-level unit
tests working...
it is _strongly_ encuraged to use the properly named methods to access
the respective columns, but opm-core's current endpoint scaling code
makes it hard to use these...
for some kinds of tables this means linear interpolation for some
columns, constant for other columns and some tables do not allow to
specify default. Since there is no clear rule, this patch involved
checking the reference manual for every single f****** table keyword
plus some guess-work if the reference manual is unclear about
monotonicity and/or defaults.
... and constant interpolation at the fringes. this kind of evaluation
in between sampling point only makes sense for tables where the first
column is strictly monotonic, though.
i.e. remove the defaultSet() method and its friends. this is required
to be able to specify defaults in DATA items like grid properties or
saturation tables. e.g.
SGL
10*0.1 10* 10*0.2 /
would not be possible without this. If no meaningful default for an
item is defined, float and double items get NaN, int items get -1 and
string ones get an empty string. The hope is that if these values get
used in the simulation, they will make the result obviously
incorrect. (Whether a data point of an item was defaulted can be
queried using item->defaultApplied(index).)
also, this renames DeckItem::setInDeck() to DeckItem::wasSetInDeck()
because the former method can easily be confused with a setter method
(which it is not, it is a 'getter').
note that there is a small semantical difference now: the old
signatures specified the status of the whole *item* while the new
variants are specific for a single *data point* of an item. Though at
this point the index passed to the methods is still disregarded..
The data values in a deck item can be in three different states, given
by the DeckValue enum in DeckItem.hpp. The three values are:
SET_IN_DECK : The value has been set explictly in the deck.
DEFAULT : The value was not present in the input deck, but a default
value has been supplied in the configuration and that value
has been set.
NOT_SET : No value has been set for this item; it was not explicitly
set in the deck and also not included in the configuration.
If you ask for DeckItem->value which is in state NOT_SET you will get an
exception. The method setInDeck() can be used to check if a value has
been set explicitly in the deck; the method defaultApplied() will check
if a default value has been applied.
Observe that the system for handling defaults is not really well suited
for multi valued data items, as it is only a scalar state variable. In
the case of multi valued data items both defaultApplied() and
setInDeck() might return true.
It turns out that the empty-record detection worked fine, but that the
last empty record of a keyword is ignored by opm-parser for reasons
which are not clear to me...
Now all unit tests pass.
In the current version, the runTimeMapTest binary was run because of a
copy-and-pasto. oops.
Also, not all of the tests pass but that is because of another problem
of opm-parser for which I don't know a good fix: It currently seems to
be impossible to specify empty records if there are non-defaulted
items in the JSON keyword specification, but such empty records are
used as table separators by Eclipse...
that's because the Eclipse capillary pressure definitions
inconsistent: SWOF specifies the "water-oil capillary pressure" as $p_o
- p_w$, while SGOF uses $p_g - p_o$ as the "oil-gas capillary pressure".
For SimpleTable, that is simply the number of records in a keyword, for
MultiRecordTables, it is the number of _empty_ records.
this patch makes supporting multi-PVT easier and cleaner.
The purpose of this flag is to keep track of whether a keyword is
supposed to have only one element, i.e. scalar, or several. The
defaultApplied method only makes sense in the case of scalar items, this
method will now throw if it is called on a non-scalar item.
this is used in opm-core but I doubt that these code paths have
actually been tested recently because the parser would have thrown up
as soon as it had encountered PVCDO...
