Open keckler opened 2 years ago
Generally I like it.
But this one:
Some of the parameters from the
blocksParameters
module also don't use the flags from theCategory
class, but they should
We do not demand that each Parameter
has a Category
. And I don't think we should.
Hm, yeah, sorry I was being a bit sloppy with that. What I mean is, for example instances like this: https://github.com/terrapower/armi/blob/1a6cb85adc900bcf531d5749367269acfe8cf9d3/armi/physics/neutronics/parameters.py#L679-L685
That parameter has a categories
entry, but it is just a string. It should pull its category from the Category
class, when that is possible.
@keckler Any updates on this ticket, after all the Parameter
work from two weeks ago?
@john-science I see that one of the items was addressed, so I marked it as such just now. But most of those boxes are still open just because they weren't the focus of any of those recent PRs.
Thanks for pinging!
@keckler This ticket is still assigned to you. That's cool with me, but if you aren't planning on working on it, please un-assign it.
(You are not being singled out, I am going through all the ARMI tickets.)
Done!
I've noticed a handful of error/inconsistencies/deficiencies in the block parameters. This is a running list for me to fix:
extSrc
in the neutronics parameters look fishyCategory
class, but they shouldblocksParameters
module also don't use the flags from theCategory
class, but they should (this is probably a more widespread problem)parameterDefinitions.Category
class, we are lacking acumulative
attribute even though many parameters are marked as "cumulative"