Adding support for ex-core structures

[john-science]

What is the change?

Added initial support for ex-core structures in ARMI.

• Blueprints can now easily define ex-core structures on their own grids.
• The old SpentFuelPool logic was rolled into the new ExcoreStructure class.
• The old AssemblyList class was removed.
• Reporting tools were updated to match.
• Docs were updated to match.

The ARMI Reactor class used to have two children that were also attributes: r.core and r.sfp. Now it has two children that are also attributes: r.core and r.excore. And r.excore is currently a dictionary where keys map to an arbitrary set of ex-core objects:

• r.excore["sfp"]
• r.excore["ivs"]
• r.excore["evst1"]

But, for convivence, you can also access these like attributes:

• r.excore.sfp
• r.excore.ivs
• r.excore.evst1

Why is the change being made?

Thus far, ARMI has really only provided a data object model for the Reactor core (and also a default spent fuel pool). The large teams that model and analyze nuclear reactors will also want to model ex-core structures for fuel handling and mechanical analysis reasons.

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify any new/changed code.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes have been updated if necessary.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in pyproject.toml.

[alexhjames]

I think I was going along the lines of more general would be more flexible. If you have a crazy reactor setup with two cores, then you would be forced into modeling one core as the core and one as excore.core2. Or similarly, if someone wanted to run analysis on the spent fuel pool like it was a reactor to verify things, then they could... Seems like it's on the plugins to know what container to look at and run analysis on.

[john-science]

Sure, we could do something more like this:

class Recctor:
    # ...

    def __getattr__(self, key):                                                                                                                                                                                    
        try:                                                                                                                                                                                                       
            return self.__dict__[key]                                                                                                                                                                              
        except KeyError:                                                                                                                                                                                           
            if key in self.excore:                                                                                                                                                                                      
                return self.excore[key]                                                                                                                                                                                 
            else:                                                                                                                                                                                                  
                raise                                                                                                                                                                                              
                                                                                                                                                                                                                   
    def __setattr__(self, key, value):                                                                                                                                                                             
        try:                                                                                                                                                                                                       
            self.__dict__[key] = value                                                                                                                                                                             
        except KeyError:                                                                                                                                                                                           
            if key in self.excore:                                                                                                                                                                                      
                self.excore[key] = value                                                                                                                                                                                
            else:                                                                                                                                                                                                  
                raise   

This allows r.sfp and r.evst1, if that's just super important to everyone.

Though I still think r.excore.sfp and r.excore.evst is more clear.

[drewj-tp]

Want to clarify that I am not likely going to be an immediate user nor stakeholder of this feature so take my suggestion w/ a grain of salt. Not a requirement

[john-science]

@drewj-tp @jakehader @alexhjames

I guess encapsulation is my goal here:

r.core - core physical object
r.excore - ex-core physical object
r.o - operator
r.id - number
r.p - parameter collection
r.cached - tooling
r.spatialGrid - tooling
r.factory - method
r.add - method
r.isFuel - method
r.backUp - method

I mean, I can make r.sfp a thing, and r.ivs, but it will mean a metric TON of error checking to make sure people don't name their excore structures id or p or o or cached or factory, because that would break the Reactor class.

And I'll have to check that no one tries to over-write the method r.factory() by doing r.factory = ExcoreStructure().

Or, in code you could set r.ivs = ExcoreStructure() , but I need to make sure you don't do r.o = ExcoreStructure().

There would just be so much error checking where I need to list every single time anyone adds or touches any method or attribute on a Reactor object. I would have to keep a full list of all attributes and methods in Reactor and it's parents Composite and ArmiObject.

[keckler]

There is at least one place in our benchmarks that will need to be migrated due to this change. We used to allow r.sfp, but now it is r.excore["sfp"].

[keckler]

First off, thank you for all of this effort. This is definitely a step in the right direction. A few comments beyond those left in the code:

1. This implementation seems to assume that any ex-core thing will be grid-like. But probably there are only so many things that might actually be like that, and something more flexible might be needed in the future. This is not a problem for this PR, more so a seed for future work.
2. There are a lot of places where we do a check to make sure that an SFP exists. But as noted by one of the comments that you added, ARMI right now is adding an SFP by default. So maybe those checks are unnecessary?
3. I support the decision to stash everything under r.excore instead of making them attributes on r directly. I think this makes sense. One comment that Alex brought up is about the possibility of having two Cores, and then one of them would have to live under excore which is weird. While I agree with this, I also think that storing two Core objects on a single Reactor doesn't make much sense from a traditional viewpoint. If Reactor were instead Plant, then maybe I'd agree more with Alex.
4. There is a lot going on here. While everything appears to look good, I will not be at all surprised if this breaks some stuff in my workflow. Oh well.

[john-science]

@john-science Test this downstream before merging.