Zones Improvements

[john-science]

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.

[jakehader]

Hi @john-science,

I agree with this but internally we need to figure out where these functionalities should live if not on the zones objects in the framework. I've also mentioned this before, but should zones be a set of assembly locations or can they be a mix of any composite?

I'd also like to have a location in the database where zones can live and operator from. Maybe this is a separate table that has a reference to the "core" that the locations belong to, but this would go a long way in helping reuse "zones" across multiple uses if they are available or just allowing some analyst to ditch what is taken from the db and recreate them as needed. Maybe there could be a getZones on the database? Not sure.

[john-science]

@jakehader There are definitely several things we need to make decisions about before this ticket can be completed. Or even worked on. At the moment, this feels like an architecture/umbrella ticket to me. The sort of thing that might require some conversations to finish, or maybe even multiple, smaller tickets.

[drewj-usnctech]

Some disparate thoughts from our internal discussions on Zones

Could plugins define their own zone builders? This could clean up that large collections of conditions checking on zoning strategies. This might tie in nicely with your comment on

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.

A couple comments on serializing to/from data file. And that feels like something that would still provide value

[jakehader]

Thanks for the input @drewj-usnctech. We are having an internal meeting next week to kick off the zones updates and changing the implementation. We will make sure to update this ticket with requirements that we derive and check that they can also work for you before proceeding. Would you be interested in being a reviewer of any new implementation?

[john-science]

@drewj-usnctech Can you share with us (broadly) what you guys use Zones for?

We are in the process of redesigning / reorganizing them, for al the reasons shown above. And we don't want to drop your use-case.

[drewj-usnctech]

@jakehader I would be happy to be involved as much as you'd like. Glad our investigation into Zones coincided with your internal meetings

@john-science sure. We are currently investigating using Zones to define material regions that should be depleted together. In order to reduce the number of depletable regions in our Monte Carlo simulation while still capturing some spatial effects, we've decided to using the zoningStrategy to assign Zones to each assembly (well most of them - #800). The idea would be if you have the same fuel material in multiple rings of your reactor, each fuel material in each ring would be depleted with the same reaction rates, spectra, etc.

The extreme extension of this would be every Assembly being it's own Zone, and somehow axially dividing so that every Block is also its own Zone

[jakehader]

@jakehader I would be happy to be involved as much as you'd like. Glad our investigation into Zones coincided with your internal meetings

@john-science sure. We are currently investigating using Zones to define material regions that should be depleted together. In order to reduce the number of depletable regions in our Monte Carlo simulation while still capturing some spatial effects, we've decided to using the zoningStrategy to assign Zones to each assembly (well most of them - #800). The idea would be if you have the same fuel material in multiple rings of your reactor, each fuel material in each ring would be depleted with the same reaction rates, spectra, etc.

The extreme extension of this would be every Assembly being it's own Zone, and somehow axially dividing so that every Block is also its own Zone

@drewj-usnctech, Is it fair to say that in your use case you are describing zones also being applied to blocks as well as assemblies at the same time, such that both composites belong to some Zones object? Im trying to understand if we were to limit zoning on the core to a set of assemblies only if that would break your use case or if that's in alignment? I was throwing the idea around if Zones can just be a set of "any" composites and if it's required that they all be the same type or if we should allow the framework to allow this. Additionally, I'm curious from your perspective if having the zones be applied as a parameter in the database would be helpful. Do you ever have instances of multiple zones existing at a single time? If so, would a parameter that was something like a dictionary with {"zoneName": set(), ...} would make sense for the framework and parameter system to support

[drewj-usnctech]

@jakehader

Is it fair to say that in your use case you are describing zones also being applied to blocks as well as assemblies at the same time, such that both composites belong to some Zones object...I was throwing the idea around if Zones can just be a set of "any" composites and if it's required that they all be the same type or if we should allow the framework to allow this

I think this would be a welcome development. In doing this, we could also use zones to do axial depletion zoning. In a more extreme case, you would also maybe include individual Component objects in a zone to let each pin be it's own depletable region, but I think that's something that could be done by whatever interface is handling Block-based depletion.

Do you ever have instances of multiple zones existing at a single time?

I might be missing something here. Only having one zone seems like a case where everything is in the same zone. Maybe you're thinking different, potentially overlapping zones? Like a depletion Zones, a different Zones for reactivity coefficients, etc?

[jakehader]

@drewj-usnctech, sorry I meant to say that different zoning for different applications like rx coeffs, XS generation, thermal hydraulics, depletion, etc. not that there would only be one zone containing all the assemblies/blocks. My dictionary example wasn't communicated correctly.

[john-science]

@drewj-usnctech, sorry I meant to say that different zoning for different applications like rx coeffs, XS generation, thermal hydraulics, depletion, etc. not that there would only be one zone containing all the assemblies/blocks. My dictionary example wasn't communicated correctly.

Jake is just hoping we can simplify things a bit to just have one set of Zones in ARMI at a time. And we don't have to assume that you have 20 ARMI plugins during a run, each with their own set of Zones. Fingers crossed.

[drewj-usnctech]

@jakehader @john-science thanks for the explanations. Our current plan is just to have one set of zones for depletion and that's it. We'll be using xs types for xs generation rather than relying on zones

[john-science]

@drewj-usnctech I am working on the Zone redesign right now with @joshuavictorchen , and it looks to me (right now), that we could save a lot of time if we could make Zones only include Assemblies and Blocks. The reasons being, both of those have a getLocation() method in ARMI.

Do you really need Component-level Zones? I ask, because you mention it above, but you didn't sounds like you were really excited about that power. And supporting only Assemblies and Blocks LOOKS like it would significantly reduce the LOE we have on this task.

[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

[john-science]

Could plugins define their own zone builders?

@joshuavictorchen and I are currently redesigning Zones from the ground up. (Sadly, it seems they need such an overhaul.)

And in our redesign, I am currently working on exactly this: making zoning strategies a lot more flexible by exposing them at the Plugin level.

The current system just seems too inflexible, particularly for people like you, who may-or-may-not even be interested in pin-style reactors.

https://github.com/terrapower/armi/discussions/811

[keckler]

Is this closed with the merge of #943 ?