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

Inherit XS Settings when creating a new XS ID #1653

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

mgjarrett
Copy link
Contributor

@mgjarrett mgjarrett commented Feb 22, 2024

What is the change?

When the cross section group manager creates a new XS ID that is based on a previous XS ID within CrossSectionGroupManager._getModifiedReprBlocks(), the new settings will now be inherited from the settings for the original XS group.

Why is the change being made?

Previously, a new XS ID would just be initialized with default cross section settings. Typically, when a user is creating a modified representative block with a new XS ID, they would want to keep the cross section settings from the original XS group.


Checklist

  • The release notes (location doc/release/0.X.rst) are up-to-date with any important changes.
  • The documentation is still up-to-date in the doc folder.
  • If any requirements were affected, mention it in the release notes.
  • The dependencies are still up-to-date in pyproject.toml.

When new XS Types are created by the cross section group manager,
initialize them with the same settings as the original XS ID from
which they were created.
@jakehader
Copy link
Member

Hi @mgjarrett - I might be misremembering but I think that we need to handle the case where the original XS settings are a link to an external cross section file or files. In that case we might need to default to 0D. Maybe I am misrememberinf why I implemented it this way.

@mgjarrett
Copy link
Contributor Author

Hi @mgjarrett - I might be misremembering but I think that we need to handle the case where the original XS settings are a link to an external cross section file or files. In that case we might need to default to 0D. Maybe I am misrememberinf why I implemented it this way.

We shouldn't be trying to make a modified representative block based on a XS group that uses pregenerated cross sections. There is a warning logged in that situation:

if self.xsTypeIsPregenerated(origXSID):
runLog.warning(
"A modified representative block for XS ID `{}` cannot be created because it is "
"mapped to a pre-generated cross section set. Please ensure that this "
"approximation is valid for the analysis.".format(origXSID),
single=True,
)

No error is thrown, and you could even end up not getting the warning, depending on the arguments passed into _getModifiedReprBlocks. Maybe we need stronger controls around this. I can't tell if the intention is actually to prevent the user from passing in pregenerated XS to this method, or just to warn and allow it anyway.

@mgjarrett mgjarrett added the bug Something is wrong: Highest Priority label Feb 27, 2024
@john-science john-science self-requested a review March 7, 2024 23:25
@mgjarrett mgjarrett self-assigned this Mar 25, 2024
@mgjarrett mgjarrett requested a review from albeanth March 25, 2024 18:46
@albeanth albeanth requested review from keckler and removed request for albeanth April 3, 2024 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is wrong: Highest Priority
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants