Skip to content
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
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

bska
Copy link
Member

@bska bska commented Sep 23, 2024

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 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
n 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.

@bska
Copy link
Member Author

bska commented Sep 23, 2024

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 bska force-pushed the generalise-rst-udq-info branch 9 times, most recently from 7c4148b to 345b7f3 Compare October 1, 2024 07:24
@bska bska force-pushed the generalise-rst-udq-info branch 5 times, most recently from 20f60b5 to 69d4b66 Compare October 2, 2024 13:08
@bska
Copy link
Member Author

bska commented Oct 2, 2024

jenkins build this please

@bska bska force-pushed the generalise-rst-udq-info branch 4 times, most recently from 580b72a to 9f8da02 Compare October 3, 2024 08:51
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant