-
Notifications
You must be signed in to change notification settings - Fork 92
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
pu frac storage update #1819
pu frac storage update #1819
Conversation
"Storing properties on the material objected will be deprecated in the near future.", | ||
single=true, | ||
) | ||
self._puFrac = puFrac |
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.
When we set the puFrac
directly, should this assume a reduction in uFrac
so that the total fraction is 1.0? I wonder if a 1.0 check should be added.
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.
i haven't gotten clear expecations for behavior on u frac or zr frac changing with depletion
puFracDefault = 0.0 | ||
uFracDefault = 0.0 | ||
zrFracDefault = 0.0 |
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.
Adding plutonium, uranium, and zirconium to a generic FuelMaterial
seems odd. We should discuss.
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.
Probably outside of the scope of this change, just a comment since this existed previously. Similar comment for @john-science in the duplicate
method.
zrFracDefault = 0.0 | ||
|
||
def __init__(self): | ||
self._puFrac = 0 |
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.
We will still need attributes for uFrac
and zrFrac
-- see duplicate
method, so we can have setters
and getters
for accessing to keep self._uFrac
, self._zrFrac
, and self._puFrac
private.
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.
code works as is (duplicate will continue to work), so we dont need them immediately without clear expectations on behavior of u and zr frac with depletion
zrFrac = 0.0 | ||
puFracDefault = 0.0 | ||
uFracDefault = 0.0 | ||
zrFracDefault = 0.0 |
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.
we need to be clear whether this is weight fraction or atomic fraction. Prefer puWtFracDefault
. The puFrac
parameter in ARMI is not weight fraction of total mass, but instead weight fraction of heavy metal.
# ideally the parameters would be stored on component, not Block (parent, not grandparent) | ||
myBlock = self.getAssociatedBlock() | ||
if myBlock is not None: | ||
return myBlock.p.puFrac |
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.
maybe myBlock.getComponent[Flags.FUEL].getMassFrac("PU")
?
This change is getting moved to a downstream ARMI application. |
What is the change?
Update materials to defer to the block's plutonium fraction
Why is the change being made?
material.puFrac is not stored in the database and materials are supposed to be stateless:
#1062
Checklist
doc
folder.pyproject.toml
.