EclWriter: forward dynamically created well connections to EclipseIO - #7328
Conversation
hnil
added
the
manual:enhancement
33919b6 to
86f2158
Compare
svenn-t
left a comment
svenn-t
left a comment
There was a problem hiding this comment.
I don't have any knowledge about dynamic well connections, so I only have some minor comments.
|
|
||
| void recordNewDynamicWellConns(const DynamicConns& newConns) | ||
| { | ||
| if ((this->rank_ == 0) && (this->eclIO_ != nullptr)) { |
There was a problem hiding this comment.
for consistency, use isIORank() instead of this->rank_ == 0
|
|
||
| public: | ||
|
|
||
| using DynamicConns = |
There was a problem hiding this comment.
Use out::Summary::DynamicConns instead?
There was a problem hiding this comment.
Use
out::Summary::DynamicConnsinstead?
Maybe. That would require including opm-common's Summary.hpp header here.
There was a problem hiding this comment.
Sure, I don't know if that has larger implications, so I'll leave it to you. Just noted the duplication.
|
jenkins build this please |
recordNewDynamicWellConns() passes fracture-created connections (well name + zero-based Cartesian cell ids) to the output layer on the I/O rank, so the summary engine can instantiate connection-level vectors for them (opm-common already provides the receiving API). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
86f2158 to
3612d06
Compare
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
jenkins build this please |
|
@svenn-t both taken:
|
bska
left a comment
bska
left a comment
There was a problem hiding this comment.
Thanks a lot for the updates. I think this looks good now. Unless someone really objects, I think this should go into the master branch.
Cool, thanks! In that case I'll merge this into the master branch. |
3 participants
recordNewDynamicWellConns()hands well name plus zero-based Cartesian cell ids for dynamically created connections to the output layer on the I/O rank, so the summary engine can instantiate connection-level vectors for them.The receiving side already exists in opm-common (
Summary::recordNewDynamicWellConns); this is only the simulator-side forwarding. Nothing upstream calls it yet — it is needed by a fracture model that creates connections during the run, which lives out of tree.12 lines, inert without such a caller.