Zones Improvements

Zones has the potential to be a pretty powerful feature in ARMI, but has a handful of issues that make it impossible or unpleasant to use for certain cases. Below are a list of concerns/grievances that should drive the overhaul"

• Can we replace Zone with a SpatialLocator?
• Because our “Zones” are so tightly coupled to SASSYS/rxcoeffs, they are probably not useful to people outside TerraPower.
• What is a hotZone?
• The Zone class shouldn’t have a addRing() method.
• A Zone behaves like a list (__getitem__() and __setitem__() are conceptually strange). Should probably be a set instead.
  • make zones behave like sets
• They are too aware of objects (addAssemblyLocations() couples the Zone to Assembly, which is not necessary. Zones should traffic only in locations)to it. It is unclear who made what, when, how, and why.
• remove core.zones. Zones should be created and owned by the interfaces that use them for whatever use they are build for. So sassys or rx coeffs would own what is currently core.zones. The other will ask the owning interface very nicely for its zones.
  • Maybe. This is debatable.
• make Core sliceable by Zone objects (e.g. core[zone] -> Set{Assembly})
• decouple the zone creation strategies from case settings. replace the above branch by a collection of static methods that return Zones build with that strategy, with appropriate arguments passed in rather than extracted from cs. This will make it easier for different parts of the code to whip zones up as they see fit, without having to fight wierd zoningStrategy settings.
• Remove zoningStrategy entirely
• They are instance attributes of a Core object. This leads to a couple of problems:
  • As instance data of an ArmiObject, zones do not survive a round trip through the database.
  • Code needs to fight over control of the zones, or the collection of zones themselves grows as things add new Zone objects
• There is only one set of settings to control zoning strategies. This drastically reduces the opportunity for reusing zones for different applications. For example:

https://github.com/terrapower/armi/blob/22ebd1a2b6bdd0ebfd14b2e56273f8351db57f82/armi/reactor/zones.py#L401-L412

Sorry if it sounds like I’m being too down on Zones. I actually think they are a great idea; they are just really held back by their current design, and with a little polish could really fly.

[keckler]

Is this closed with the merge of #943 ?

[drewj-usnctech]

@john-science I don’t think Component-level Zones are necessary at this time. I imagine there might be a case for them somewhere but I’m struggling to think about it for now. Almost all of the use cases could be covered instead with some Block.getChildren(flags=...) type searching.

I feel good about only including Assembly and Block objects in Zones