Commit Graph

4 Commits

Author SHA1 Message Date
Andreas Lauser
6dbe6ae5ac remove the "value status" concept from deck items
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)...
2014-09-15 12:17:04 +02:00
Andreas Lauser
e6fa1e01a8 DeckItem: add indices to the methods which allow to query the defaulted status
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..
2014-09-15 12:17:03 +02:00
Joakim Hove
61cdf7d402 Default: defaultApplied -> setInDeck()
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.
2014-09-03 10:37:01 +02:00
Bård Skaflestad
ef5a9e8e1a Refactor WellProductionProperties manipulation code
This commit splits the creation of WellProductionProperties objects,
and especially the ad-hoc helper functions historyProperties()
and predictionProperties() out to a separate module,
WellProductionProperties.[hc]pp.  Creating the properties object
from a DeckRecordConstPtr is deferred to two named constructors,

    WellProductionProperties::history() and
    WellProductionProperties::prediction()

that, respectively, assume the roles of historyProperties() and
predictionProperties().  Reimplement handleWCONProducer() in terms
of these named constructors and remove the producerProperties()
helper whose task, inspecting the status and retrieving/setting the
CMODE if not SHUT, can be assumed by handleWCONProducer().

Add a simple test module, WellPropertiesTest.cpp, to enforce the
rather peculiar semantics of the WCONHIST keyword.  Control modes
{O,W,G}RAT, LRAT, and RESV are *always* (unconditionally) supported
in WCONHIST but there is no control mode switching.  The latter is
deferred to client code, depending on the '.predictionMode' flag.

Suggested by: [at] joakim-hove
2014-07-08 13:22:46 +02:00