Fixes a bug where completions specified after a record just updated a
completion would be assigned a too high completion number.
COMPDAT can be used to re-specify some properties of connections, in
which case they're not actually new completions and the completion
number shouldn't change.
Connections are given a completion number starting at 1 implicitly when
they're first defined by the COMPDAT keyword. Until now this number has
been ignored.
The number itself isn't *used* for anything with this patch, just stored
and accessible.
The reference depth is not a static property on first creation, but can
change on subsequent WELSPECs. Wrap the ref depth in DynamicState to
handle this.
Well.headI and Well.headJ was assumed to be fixed on first declaration,
and that all subsequent changes of this position was an error. This
turns out not to be the case, so the I/J positions are made dynamic.
/home/mblatt/src/dune/opm/opm-parser/opm/parser/eclipse/EclipseState/Schedule/GroupTree.cpp: In member function ‘void Opm::GroupTree::update(const string&, const string&)’:
/home/mblatt/src/dune/opm/opm-parser/opm/parser/eclipse/EclipseState/Schedule/GroupTree.cpp:39:76: warning: declaration of ‘parent’ shadows a member of 'this' [-Wshadow]
void GroupTree::update( const std::string& name, const std::string& parent ) {
^
/home/mblatt/src/dune/opm/opm-parser/opm/parser/eclipse/EclipseState/Schedule/GroupTree.cpp: In member function ‘std::vector<std::basic_string<char> > Opm::GroupTree::children(const string&) const’:
/home/mblatt/src/dune/opm/opm-parser/opm/parser/eclipse/EclipseState/Schedule/GroupTree.cpp:76:77: warning: declaration of ‘parent’ shadows a member of 'this' [-Wshadow]
std::vector< std::string > GroupTree::children( const std::string& parent ) const {
1. Removed Tabdims(int,int,int, ....) constructor and added
Tabdims(Deck) constructor.
2. Added Tabdims member to Runspec( ) object.
3. Changed std_shared_ptr<Tabdims> to Tabdims member in TableManager.
The WellSet class is replaced by std::set, allowing predictable copy
semantics of Group. This change has rather few consequences as accessing
a well through a wellset was hardly ever done.
Getting hold of the corresponding well instance will now have to be done
via a Schedule instance - however, this simplifies the dependency graph
by severing the edge between the Group object and Well objects.
Replaces The GroupTree + GroupTreeNode classes building an explicit tree
of named nodes with a sorted vector of { name, parent-name } pairs that
builds an implicit tree. Provides the same semantics as the previous
group tree implementation, but with less code and copying for free.
Replaces the internal inheritance + unique_ptr scheme to a flat sum type
similar scheme that uses a tag to determine which operations are legal,
rather than using the indirection itself as a tag.
The SKIPREST keyword is really only needed in eclipse - since we parse
through the entire deck and create a complete internal representation
with random access, we don't need to actually skip parts of the input.
The old behaviour was to mimic some possible failure modes for eclipse,
however this has caused issues for no real benefit.
refs:
* https://github.com/OPM/opm-parser/issues/773
* https://github.com/OPM/opm-parser/issues/960
There has never really been a natural home for initial properties that
aren't InitConfig, meaning information such as phases in the deck and
other runspec information hasn't had a natural home.
This patch introduces the Runspec object on EclipseState for phase
information and other similar properties that are interesting and static
for when setting up parameters etc. for simulation, that aren't all that
interesting once simulation starts.
An additional benefit is a leaner implementation for the phase enum and
some stricter semantics via enum classes.
1. Will retain already set values when only some items are set.
2. Will parse the sections before the SCHEDULE section to create a
correctly initialized MessageLimits object.
for some reason, it looks like `std::find_if()` does not work on
ubuntu 16.10 with clang and enabled optimizations. since as far I can
see this 'if' is a minor performance improvement in non-time critical
code, let's just remove the condition.
