-
Notifications
You must be signed in to change notification settings - Fork 112
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
Generalise Restart Representation of UDQs #4225
Draft
bska
wants to merge
2
commits into
OPM:master
Choose a base branch
from
bska:generalise-rst-udq-info
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I am creating this PR in draft mode because it depends on, and contains, the earlier PR #4224. I will keep the PR in a draft state until such time as it is ready for review and merging. That may be after we've created the release branches for the 2024.10 OPM release, since it's not clear to me that this is ready to go into a release version quite yet. |
bska
force-pushed
the
generalise-rst-udq-info
branch
9 times, most recently
from
October 1, 2024 07:24
7c4148b
to
345b7f3
Compare
bska
force-pushed
the
generalise-rst-udq-info
branch
5 times, most recently
from
October 2, 2024 13:08
20f60b5
to
69d4b66
Compare
jenkins build this please |
bska
force-pushed
the
generalise-rst-udq-info
branch
4 times, most recently
from
October 3, 2024 08:51
580b72a
to
9f8da02
Compare
This commit ensures that all known UDQ variable types (e.g, field, group, well, segment) are accounted for in the INTEHEAD restart vector. We switch to having an appropriately sized std::array as a member in InteHEAD::UdqParam represent the counts instead of having individual members for each variable type. This is more extensible as well if we add more categories in the future. We generate the category counts to class UDQConfig, since this class already knows the category counts internally (from UDQConfig::add_node()). To this end, add a new member function 'UDQConfig::exportTypeCount()'. While here, make slight whitespace adjustments to the IUAP and IUAD counting routines to simplify future maintenance.
This commit reimplements the RestartIO::RstUDQ type with a view towards introducing support for restarting simulation runs containing user defined quantities (UDQs) associated to the segments of multi-segmented wells. In particular, we replace the current value container with a back-end based on the CSRGraphFromCoordinates helper class. This, in turn, enables supporting UDQ values at the sub-entity level of a top-level entity such as the segments of a multi-segmented well. We more clearly distinguish the producing side--i.e., the layer which loads information from a restart file--from the consuming side--i.e., the client code which forms UDQConfig and UDQState objects based on the restart file information, and require the producing side to signal when the restart information has been fully loaded. To this end, the producing side is expected to 1. Call member function prepareValues() to signal that new values are being loaded 2. Call member function addValue(), typically in a loop, to include new UDQ values from the restart file 3. Call member function commitValues() to signal that all values have been loaded. As an alternative to step 2, the producing side may call member function addScalarValue() if the quantity in question is scalar--typically a field level UDQ. The producing should also include any relevant entity names, usually well or group names, by calling the addEntityName() member function. The consuming side is expected to interact with the information through operator[]() which returns a specialised ValueRange type that supports forward iteration, for instance in a range-for() loop. This new interface begets a significant update to the UDQAssign class. In particular, we no longer need the 'rst_selector' and instead add new constructor and add_record interfaces which take a RestartIO::RstUDQ object and a report step index. The previous interface based on the 'rst_selector' implicitly assumed that all assignment statements applied a constant value to a collection of wells or groups, but this assumption does not generally hold when we load information from a restart file. The new interface removes this assumption. While here, also make the AssignRecord into a private data type since client code does not generally need to know how we represent the assignment information. Finally, add Doxygen-style documentation to the types * RestartIO::RstUDQ * UDQAssign * UDQConfig While not much, this may help future maintainers understand the relationships between these types a little better.
bska
force-pushed
the
generalise-rst-udq-info
branch
from
October 4, 2024 15:55
9f8da02
to
0020f0d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reimplements the
RestartIO::RstUDQ
type with a view towards introducing support for restarting simulation runs containing user defined quantities (UDQs) associated to the segments of multi-segmented wells. In particular, we replace the current value container with a back-end based on theCSRGraphFromCoordinates
helper class. This, in turn, enables supporting UDQ values at the sub-entity level of a top-level entity such as the segments of a multi-segmented well.We more clearly distinguish the producing side–i.e., the layer which loads information from a restart file–from the consuming side–i.e., the client code which forms
UDQConfig
andUDQState
objects based on the restart file information, and require the producing side to signal when the restart information has been fully loaded. To this end, the producing side is expected toprepareValues()
to signal that new values are being loadedaddValue()
, typically in a loop, to include new UDQ values from the restart filecommitValues()
to signal that all values have been loaded.As an alternative to step 2, the producing side may call member function
addScalarValue()
if the quantity in question is scalar–typically a field level UDQ.The producing should also include any relevant entity names, usually well or group names, by calling the
addEntityName()
member function.The consuming side is expected to interact with the information through
operator[]()
which returns a specialisedValueRange
type that supports forward iteration, for instance in a range-for() loop.This new interface begets a significant update to the
UDQAssign
class. In particular, we no longer need therst_selector
and instead add new constructor and add_record interfaces which take aRestartIO::RstUDQ
object and a report step index. The previous interface based on therst_selector
implicitly assumed that all assignment statements applied a constant value to a collection of wells or groups, but this assumption does not generally hold when we load information from a restart file. Then ew interface removes this assumption. While here, also make the
AssignRecord
into a private data type since client code does not generally need to know how we represent the assignment information.Finally, add Doxygen-style documentation to the types
RestartIO::RstUDQ
UDQAssign
UDQConfig
While not much, this may help future maintainers understand the relationships between these types a little better.