Save `zones` information to the database

[joshuavictorchen]

zones are not currently saved to reactor database files, so information pertaining to them is lost for workflows where databases are manually transferred between users.

I suggest updating the framework to save zones information to the reactor database. Adding them as a dataset to the existing layout group seems appropriate.

[john-science]

People can create arbitrarily any zones they want, right? With any amount of complexity, duplication, or with no rhyme or reason?

I think the big task for this request would be to define a data structure in the DB that could store this arbitrary data.

The usual solution would be to make "zones" a parameter. Though I'm not thrilled with that solution here. So we would need to find a more unique/bespoke way to track zones. Nothing jumps to mind.

Any ideas @joshuavictorchen?

[joshuavictorchen]

Yes, zones can be anything we dream of, but only at the assembly or block level: https://github.com/terrapower/armi/blob/4f55d94d56cb81f3bd44714082c3295eea16853f/armi/reactor/zones.py#L37

It looks like the layout group contains datasets describing each composite in the database.

So a simple (admittedly a bit backwards?) way to track zones could be to identify which zone each composite is in (if any) and add a zone dataset to the layout group. For simplicity, we may limit this tracking to assembly and block objects - everything else can remain unzoned.

We could add a function that looks at the layout group and reconstructs the zones upon loading a reactor database.

I realize this would be much clearer with an example (which I may provide if time permits), but hopefully this makes some sense. FWIW, this is not a top priority right now, though it may become more relevant within the next year.