-
Notifications
You must be signed in to change notification settings - Fork 90
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
Refactoring Material to not subclass Composite #1062
Conversation
@drewj-usnctech Just FYI |
Thanks @john-science Quick skim and nothing seems to jump out to me here |
@@ -73,7 +87,8 @@ class Material(composites.Composite): | |||
with information about thermal scattering.""" | |||
|
|||
def __init__(self): | |||
composites.Composite.__init__(self, self.__class__.name) | |||
self.parent = None |
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.
Why do materials still have parents? They shouldn't, since they're no longer in the hierarchical tree.
Remove or justify with implementation docs.
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.
It appears to me that the mass fractions in all ARMI materials are designed to be changed by the user's choice of nuclides. And right now those nuclide choices come from the parent.
Can you enlighten me on this? Because these nuclides are also the reason materials have parameters.
ARMI materials seem to change a LOT based on the nuclides present in ARMI, and those nuclide are not static in ARMI.
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.
Materials used to be the place where composition (defined as number density vectors of elements and nuclides) was stored. We moved that to the Component
's numberDensities
param long ago.
However, we still initialize this param based on the Material
s that users add to their problem via the Material.setDefaultMassFracs
method, which sets Material.p.massFrac
. This is indeed (and unfortunately) a bit coupled to nuclide choices, since sometimes users want to model Carbon while other times they want to model Carbon-12.
So may be we need an intermediate ticket here, with the goal of: "Decouple composition definitions from neutronics library assumptions".
Material definitions should be static and evergreen, not dependent in any way on user modeling settings. This should include initial material composition, and probably also the process of building Component numberDensities
, and potentially even the evolution of composition vs. time from transmutation and decay and reprocessing and everything else. The user modeling settings that map compositions to specific subsets of nuclides based on neutronics library needs should be isolated to the neutronics physics modules. For example, if a neutronics input is being built for a code that only has C-12 but the composition has Carbon, a mapping between carbon and C-12 should happen as the input is being written.
At this point, changing setDefaultMassFracs
to getDefaultMassFracs
in a way that just returns the data might be workable, and just eliminate Material.p.massFrac
altogether. We'll have to see how much code accesses p.massFrac
and assess how exactly to pull off an upgrade like this.
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.
Okay, the list of parameters that Material
needs is short. I just removed two with no trouble, and a third is only used in UThZr
.
I think this PR could probably be merged in as-is.
But for now, let me see if I can attack the situation with a process like this:
- The original PR, just removing the
Material(Composite)
subclass. - Remove all the
Material
Parameter
except themassFrac
ones. - See if it's possible to remove
Material.p.massFrac
- Finally remove the
Material
metaclass.
I think (3) above is by far the hardest. So I will see how far I get and if that needs to be its own PR. I'm experimenting now.
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.
Okay, I have made progress. I have removed all Parameter
s from Material
and FuelMaterial
except massFrac
.
I'm hoping I'll remove that today, and we can re-open this PR.
(I have also prepped 7 parallel PRs to update downstream repos to match this one.)
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.
Done.
Okay, I removed a lot of code, so I'm sure the code coverage will go down. BUT Material
not longer has any Parameter
s.
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.
ok, please just add docs in the code explaining why there's a parent and what's to be done about it.
armi/materials/material.py
Outdated
def backUp(self): | ||
"""Empty because statelss materials shouldn't use cache""" | ||
pass | ||
|
||
def restoreBackup(self, paramsToApply): | ||
"""Empty because statelss materials shouldn't use cache""" | ||
pass | ||
|
||
def clearCache(self): | ||
"""Empty because statelss materials shouldn't use cache""" | ||
pass | ||
|
||
def _getCached(self, name): | ||
"""Empty because statelss materials shouldn't use cache""" | ||
return None | ||
|
||
def _setCache(self, name, val): | ||
"""Empty because statelss materials shouldn't use cache""" | ||
pass |
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.
Can we just delete all these?
Spelling error: stateless
Big picture: have you measured the performance impact of not caching the material properties vs. temperature? That was a hugely major performance bottleneck we identified through formal profiling of test cases.
We need to see a profiler trace of loading a reactor and printing out all number densities in order to judge this. Can you paste the before/after highlights of the profiler results as a comment to this PR?
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.
Two questions:
- Isn't a cache a "state" for the class?
- In downstream repos, we have temperature-dependent densities. These caches will preserve the first value they get forever. Shouldn't that lead to incorrect material densities?
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 will look into this more once I have fully removed the Parameters from Material
s.
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.
Done.
Since Material
no longer subclasses Composite
, I had to mostly copy them over from the Composite
class. But now they aren't blank here any more.
Thanks for the heads up @john-science 👍 |
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.
looks great, thanks! Just some minor comments.
@@ -40,7 +40,7 @@ def __init__(self): | |||
by a constant user-input density. | |||
""" | |||
Material.__init__(self) | |||
self.p.density = 1.0 | |||
self.customDensity = 1.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.
kind of a minor point but if we're renaming things like this it might be wise to make them supernames like customDensityInGPerCC
. As it turns out, putting units in names is one honkin good idea, especially for super generic terms like 'density'
@@ -73,7 +87,8 @@ class Material(composites.Composite): | |||
with information about thermal scattering.""" | |||
|
|||
def __init__(self): | |||
composites.Composite.__init__(self, self.__class__.name) | |||
self.parent = None |
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.
ok, please just add docs in the code explaining why there's a parent and what's to be done about it.
…30/assembly-1d-parent-class * terrapower/main: Updating B4C docstring for assumed TD frac (terrapower#1117) bug fix for xsGroup manager w/ coupling (terrapower#1118) Add neutronics category to linPow parameter (terrapower#1119) Refactoring Material to not subclass Composite (terrapower#1062) Exposing tight coupling to `OperatorSnapshots` (terrapower#1113)
Description
This PR refactors the
Material
class to no longer be a subclass ofComposite
.It also removes (most, not all) of the statefulness in ARMI Materials. For instance, I removed all
Parameter
s fromMaterial
. Some of those I copied over to a simpler class attribute (mat.p.massFrac
becamemat.massFrac
). And some I was able to delete entirely (likeyieldStrength
andatomFracDenom
).Also, I should note that three parameters (
uFrac
,puFrac
, andzrFrac
) applied only to FUEL materials, but were defined by default for all materials. That was fixed.Stateful things I haven't removed in this PR (because they are going to be tricky):
Custom
materials, which are obviously stateful by design.Material
class still has aself.parent
, which is necessary for a whole LOAD of logic to do withMaterial.getNuclides()
. (@ntouran Please note this proved to be a big enough change that if we want to remove it, it will be it's own PR.)@drewj-usnctech @sombrereau In any repo I can see, I am making PRs to match this one. But if you have a private repo I can't see, 99% of the changes are just to switch calls to
mat.p.thing
tomat.thing
. (Once, a material outside ARMI needed an__init__()
method, that it didn't have before.)Checklist
doc/release/0.X.rst
) are up-to-date with any bug fixes or new features.doc
folder.setup.py
.