Improve feature designations #1
Description
Currently, the high-fidelity and reduced-order solvers indicate their provided physics and needs based on namedtuples in hydep.internal.features
hydep/src/hydep/internal/features.py
Line 13 in e73c06a
This is kind of obtuse and not well documented, which was fine when just one person had eyes on the source. But I think this feature designation should be improved to
- Provide more clarity into what each feature / need means and how they should be resolved
- Make it easier for developers to add features through an API rather than source code (e.g. subclass Serpent solver, add a method and some new physics)
- Provide a cleaner approach for resolving features on the high fidelity solver side
Some things to consider for the naming going forward. The SFV solver is quite simple in that it only needs homogenized macroscopic cross sections in the burnable materials. But, if we add interfaces for a nodal diffusion code or deterministic transport, we will need these cross sections (and more) in non-burnable materials, and possibly on a per-universe level.
Specifying the level of homogenization for some features will be necessary too, e.g. just burnable, all materials, per assembly of pins (how to find that? A depth / level argument?)
Ideas
Something like pluggy may be nice. I've had my eye on it for a minute but haven't prototyped it out. But maybe not since we may want one method to satisfy multiple features (e.g. the gcu writer in the Serpent interface getting homogenized cross sections for more than just burnable materials)
Maybe some kind of bit field / mask for the features? I've seen this in armi and the API is quite slick. Rather than checking if a feature is contained in a set (like the current feature collection), we could do something like
if solverNeeds & Features.FISSION_MATRIX:
# do something to get the fission matrixThis is similar to using enum.Flag but with a way to register features with an API.