-
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
Move a/b.p.detailedNDens
to internal plugin
#1702
Comments
The question in ARMI is always "Is this idea generally useful to reactor modeling". Now, maybe some ideas are specific to LWRs or SFRs or hex-assemblies, but those are still worth including in ARMI for a good chunk of the target audience. In that light, this
|
I've always thought that ARMI had too many parameters that aren't actually tied to anything in ARMI. We just assume that people will want to use them (which I think is a questionable assumption, personally). I imagine that most people, if they're taking the time and effort to write their own ARMI Application, will want to write their own parameters and not rely on the defaults in ARMI. I think it would be cleaner (and easier to maintain by not having to ask permission or surprisingly wrecking someone's App) if we only left the most obvious ones in ARMI (e.g., flux, keff, pitch, other geometric info, etc) or ones that are actually used in ARMI. These could serve as examples for others to develop their own. Thoughts? |
I very much agree with this sentiment. It is not difficult for the creator of an App to define their own parameters. I think that stuffing the open-source ARMI with maybe-useful parameters is only to our detriment. |
Agreed. So far, we have removed ~150 Parameters from ARMI. But these are breaking changes, and some of those parameters are used downstream, so they have to be moved carefully rather than just deleted. I was able to just straight delete 100-120 parameters, but that did take weeks of discussion to do. If there is support, I would be happy to do more. Perhaps there are bulk groupings of parameters we could consider all at one time. Say, if there was a particular TH or neutronics application that wanted to take responsibility for a bunch of ARMI parameters and move them out of ARMI... that could be really helpful. :) |
I'll start an internal discussion! |
Okay, after some discussion, we've decided to just move this parameter out of ARMI. |
Also, the |
Drat. This parameter is actually used directly in ARMI: Lines 727 to 745 in 9ea428b
It is called in one place: Lines 685 to 706 in 9ea428b
So, this probably isn't a simple copy/paste any more. Let me look at this. |
The parameter
detailedNDens
is defined for both blocks and assemblies in the framework. Here are both of those definitions:armi/armi/reactor/assemblyParameters.py
Lines 134 to 147 in 1e356e7
armi/armi/reactor/blockParameters.py
Lines 51 to 65 in 1e356e7
There are a couple minor issues with these parameters being defined here:
burnxDetailedDepletion
), and that setting is internal to TP's ARMI appnFe56
,nU238
, etc.) and is thus confusingIn order to disambiguate the situation, it would be great if we could add context to the parameter's description that, for instance, it is only set when
burnxDetailedDepletion
is turned on. In order to do that, the setting would have to be made internal.I think there would be value in bringing this hyper-specific setting internal. The setting definition says as much in a comment, so I don't anticipate this would break anything.
The text was updated successfully, but these errors were encountered: