I know it was only added recently, but all of the "setInDeck()" calls
can now be substituted by a combination of item->size() and
item->defaultApplied(index)...
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..
these are not really documented, but they are used by the file
./INCLUDE/SUMMARY/extra.inc of the Norne deck. I don't know why this
did not bite anyone so far, probably people just commented out the
INCLUDE statement of this file...
The class Value<T> will keep track of a named variable, and whether that
particular value has been explicitly initialized. Will throw
std::logic_error if trying to use an unitialized value.
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.
This is the first of several large commits changing several aspects of
the handling of defaults. The overall main purpose of these changes is
to protect against using non sensible values in the case the values have
not been sensibly specified in the deck. The changes in this commit
include:
1. The "default default" values to be used when an item without an
explicit default are defaulted are removed completely.
2. If a ParserItem is queried for a default value when no default has
been assigned it will raise an exception.
We now have an enum which can keep track of three possible states for
the data in a deck item:
VALID : A valid value has been set
DEFAULT : The default value has been applied
NOT_SET : The value has not been set.
The intention is to throw if/when a DeckItem with status == NOT_SET is
accessed.
this is required in situations where double grid properties depend on
the values of integer (i.e, *NUM) ones which appear later in the
deck. Example:
```
PROPS
SWU
* /
REGIONS
SATNUM
*2 /
```
the default value of the SWU keyword depends on the value of the
SATNUM property which only gets defined later in the deck. an
alternative to the approach of this patch would be to process the
grid properties of the REGIONS section before the others. I'm a bit
indifferent which approach is better...
It seems like some optimization passes of CLang which are enabled by
-O2 (at least in my version, 3.3) do not like nested scopes and long
functions too much. Thus, slightly change the generated source. Timing
on my (quite beefy) machine:
without patch:
make
rm -rf generated-source; time make
time make
[...]
real 10m31.110s
user 10m16.264s
sys 0m13.672s
with patch:
make
rm -rf generated-source; time make
time make
[...]
real 0m47.011s
user 0m44.670s
sys 0m1.968s
the memory used by the compiler goes from 28.8GB to about 330 MB. (I
suppose not everybody has 32 Gigs of memory yet. ;)
these includes are required by the headers. If the affected files
would have been included without the headers included before, a
compiler error would have been produced.
