Allow for Multiple Eigenvalue and Fission Source Tolerances

[Nebbychadnezzar]

The settings epsEig, epsFSAvg, and epsFSPoint (settings.neutronics) are generally used throughout the life cycle of a calculation. (It is noted that these names are tailored to DIF3D). These settings control the convergence of k-effective and the fission source, and they are simultaneous enforced by DIF3D. In order to get either eigenvalue or fission source convergence (the latter encompassing the former), the user chooses appropriate values for epsEig and epsFSAvg/epsFSPoint.

In a given lifecycle, there is commonly a desire to use both types of convergence for different parts during the calculation. For example, one would typically want to use eigenvalue convergence during a critical rod search, while one would typically want to use fission source convergence during a power distribution calculation.

However, with only one set of tolerances available for all DIF3D calculations, the user is typically forced to pick the more constraining of the tolerances, which is fission source tolerances. This in turn forces the user to waste a lot of solver time on outer iterations (>50% of the total outers) for calculations where only eigenvalue convergence is required (e.g., critical rod searching).

It is worth considering implementing two sets of convergence parameters, one for eigenvalue calculations and another for flux calculations. These can then be implemented for the specific calculation type during a run.

[john-science]

It is worth considering implementing two sets of convergence parameters, one for eigenvalue calculations and another for flux calculations. These can then be implemented for the specific calculation type during a run.

My gut here says we need to just add new Parameters for eigenvalue calculations in the flux solver. Just new parameters.

Which I'm in favor of. Sure, easy.

The only "real question" I have left is: Do we want those new flux-solver-eigenvalues to be Parameters in ARMI, or just in the downstream flux solver ARMI plugin.

Thoughts?

[jakehader]

I think that the request generally is to figure out if we can have more interface based settings rather than parameters. These settings are quite generic so they get reused but I don't think we need new parameters here. Can a plugin register settings?

[Nebbychadnezzar]

I think that the request generally is to figure out if we can have more interface based settings rather than parameters. These settings are quite generic so they get reused but I don't think we need new parameters here. Can a plugin register settings?

Right. Just making case settings names up, but something like:

epsEig-cheap, epsFSAvg-cheap, and epsFSPoint-cheap for when a cheap calculation is desired and epsEig-expensive, epsFSAvg-expensive, and epsFSPoint-expensive for when an expensive calculations is desired. When an interface is getting ready to do a calculation, depending on what it's up to, it would use of those two sets.

[jakehader]

I'd also like to the utility of having settings be applied by package name space as an option to:

Settings:
   globalSetting1: value
   globalSetting2: value
   Plugin/Package Name:
       localSetting1: value
       globalSetting2InContextOfLocalBehavior: value

This might add a lot of complexity versus just making unique setting names, but @john-science would you be able to set up a meeting with us to discuss?