-
Notifications
You must be signed in to change notification settings - Fork 99
Additional information on the table log perforation #3966
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
| /// The reservoir element that contains the perforation | ||
| globalIndex m_reservoirElementID; | ||
| /// the target region name for the reservoir element | ||
| string m_regionName; | ||
| /// the target sub region name for the reservoir element | ||
| string m_subRegionName; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A WellElementSubRegion can only have one communicating region cell element?
Isn't this data already stored somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep I revert wellElementSubRegion cpp & hpp
| localIndex & esrMatched, | ||
| localIndex & eiMatched, | ||
| globalIndex & giMatched, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you may have a lot of parameters here, maybe a functor with a structured parameter would be simpler to call than a lot of in-out parameters.
Also, the return type is not documented, it is a EOF-style-bool, right? With a functor you could have the loop inside of the search method.
Before the modification :
After