Compositional well #4334
Compositional well #4334
Conversation
|
jenkins build this please |
| // injection streams for compostional STREAM injection using WINJGAS | ||
| std::unordered_map<std::string, std::vector<double>> inj_streams; |
There was a problem hiding this comment.
Please use map_member<>. It really is the primary solution to this problem.
There was a problem hiding this comment.
Sure. I went back and forth on this and thanks for the suggestion. I will do that.
not very familiar with the design here. Will you explain a little bit what is the difference here for future record?
There was a problem hiding this comment.
not very familiar with the design here. Will you explain a little bit what is the difference here for future record?
Sure. The point is that map_member<K,V> is more or less a map<K, shared_ptr<V>> with some additional logic on top. This enables sharing data between ScheduleState objects at different report steps if there is no intervening keyword to add/change the data.
There was a problem hiding this comment.
The design looks like V needs to be a struct containing name() , which is the key .
There was a problem hiding this comment.
Is it okay that I add a member function
void update(const K& key, std::shared_ptr<T> value);or you think it will break the design.
There was a problem hiding this comment.
It looks it might work, but it will be on draft mode for some while until we figure out how things work in the opm-simulators. I will check what Jenkins think about it.
If it does not work later, I will make a StreamComposition struct to make it the same with Well or Group to following the design style.
GitPaean
force-pushed
the
compositional_well
branch
from
5f80b49
to
0eb6da9
Compare
|
jenkins build this please |
GitPaean
force-pushed
the
compositional_well
branch
3 times, most recently
from
b14f594
to
3311e2c
Compare
GitPaean
force-pushed
the
compositional_well
branch
from
11898aa
to
c1cf35e
Compare
No description provided.