search

terrapower / armi

An open-source nuclear reactor analysis automation framework that helps design teams increase efficiency and quality
https://terrapower.github.io/armi/
Apache License 2.0
235 stars 89 forks source link

add capabiltiy to define assembly blueprints info in matrix form instead of just lists #1143

Open onufer opened 1 year ago

onufer commented 1 year ago

Right now this is the way to define assembly block modifications


    inner fuel:
        specifier: IC
        blocks: &fuel_blocks
            - *block_reflector
            - *block_fuel
            - *block_fuel
            - *block_fuel
            - *block_fuel
            - *block_fuel
            - *block_plenum
        height: *heights
        axial mesh points: *mesh
        material modifications:
            U235_wt_frac:
                - ''
                - 0.127
                - 0.127
                - 0.127
                - 0.127
                - 0.127
                - ''
        xs types: &IC_xs
            - A
            - A
            - A
            - A
            - A
            - A
            - A

when there are only 6 items its pretty easy to not be off-by-1, but when there are 30+ items (like in some internal inptus)its a lot more difficult. Having an option to alternatively use matrix form would be much less error prone (this doesn't have to be final format)

    inner fuel:
        specifier: IC
        blocks Specs: &fuel_blocks
            - [Blocks,            material modifications, xs types]
            - [*block_reflector,  '',                     A]
            - [*block_fuel,       0.127,                  A]
            - [*block_fuel,       0.127,                  A]
            - [*block_fuel,       0.127,                  A]
            - [*block_fuel,       0.127,                  A]
            - [*block_fuel,       0.127,                  A]
            - [*block_plenum,     '',                     A]
        height: *heights
        axial mesh points: *mesh
onufer commented 1 year ago

tagging @john-science to get his thoughts. not uber high priority.

jakehader commented 1 year ago

This would be nice! Maybe not supported by yamlize and yaml off the shelf?

onufer commented 1 year ago

Thats a good point. ill probably give it a go if @john-science this its good. If i cant make good progress in a couple hours ill give up and report back.

john-science commented 1 year ago

It's an interesting idea.

I haven't been able to look into this yet. We need the change to be optional/backwards compatible, that's important. And changes to the accepted blueprints format can get hairy, because we have all different kinds of supported blueprints (rectangular grids versus RZTheta grids, for instance). So without looking into it, I don't know if this change would have to be made in multiple places.

The IDEA though, looks nice. I just don't have a clear LOE on if this is easy or hard without spending a little time on it.

onufer commented 1 year ago

cool. ill try to do something in the april time frame. we need backward compatible for sure. Different geoms have very simlar assembly declaration.

i expect the big lift will be yamlize as @john-science says

onufer commented 1 year ago

@john-science, i think we get most of the benefit here without needing round trip if the work flow was

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

input format | what yamlize sees | what gets roundtripped -- | -- | -- matrix input | list input | list input

that would get us 99% of what we want. so just a pre-processor before the string is sent to yamlize would be enough. Backwards is nice and all but most time you are writing blueprints back you are less concerned with the exact format.

john-science commented 1 year ago

yamlize doesn't directly support this. It only supports the original "list type" of formatting YAML data.

I have been looking at if it will be easier to add this feature in ARMI or in Yamlize. TBD

john-science commented 1 year ago

One interesting point is that YAML, as a whole, will never write out a file with custom whitespace like that. So even if we can allow such files as input, they will also be written out with one space between each element in the list. So they will never vertically-align on write in such a pretty way.

That's in both of the base Python YAML libraries. Which I'm not keen to rewrite or replace.

So, there's a wrinkle. Hmmmm

john-science commented 1 year ago

Okay, we just had a meeting on this ticket, let me summarize.

Cons

Our input and output files will no longer be valid YAML.

All YAML readers, formatters, and linters will need to be replaced.

We will have to build and support our own file type.

Pros and More

drewj-tp commented 1 month ago

I like this idea. Once you get beyond a small number of blocks in an assembly, tracking what block gets xs, heights, mesh points, modifications, etc. gets untenable fast.

I'd like to be involved in discussing the new structure if/when we pick it up

john-science commented 1 month ago

This ticket will take about a month. It is a big effort.

Also:

drewj-tp commented 1 month ago

This ticket will take about a month. It is a big effort.

Agree

Also:

  • It will break input file round-tripping
  • It will break everyone's IDE, since XCode will say this is no longer a valid YAML file.

I think there's a way to get the same goal (defining more block data next to the block) w/o making invalid yaml. YAML allows lists of maps like

>>> data = [{"block": "sample", "height": 10, "xs type": "A"}, {"block": "another", "height": 5, "xs type": "B"}]

>>> print(yaml.dump(data))
- block: sample
  height: 10
  xs type: A
- block: another
  height: 5
  xs type: B
jakehader commented 4 weeks ago

This ticket will take about a month. It is a big effort.

Agree

Also:

  • It will break input file round-tripping
  • It will break everyone's IDE, since XCode will say this is no longer a valid YAML file.

I think there's a way to get the same goal (defining more block data next to the block) w/o making invalid yaml. YAML allows lists of maps like

>>> data = [{"block": "sample", "height": 10, "xs type": "A"}, {"block": "another", "height": 5, "xs type": "B"}]

>>> print(yaml.dump(data))
- block: sample
  height: 10
  xs type: A
- block: another
  height: 5
  xs type: B

You'd probably not want to do this since it would explode the number of block definitions in the blueprints so reuse of a block design would essentially go away.

I think round tripping could be preserved if we allowed for assembly block specifications (e.g., material mods, heights, XS types, etc.) to be input as a multi line string and then parsed. I think the parsing would need to be delimited and ultra strict in terms of data sizes and key / value pairs to prevent user errors. This could probably be achieved with a custom validator.

I +1 this idea because it would be nice to be able to easily go from a spreadsheet with rows and columns and also much easier to visually inspect.

drewj-tp commented 4 weeks ago

You'd probably not want to do this since it would explode the number of block definitions in the blueprints so reuse of a block design would essentially go away

I'm not implying we'd put the height and xs type in the block def. That would absolutely be a problem. More making the assembly def as a list of maps. More vebosely

assemblies:
  fuel:
    slices:
      - block: *block_fuel
         height: 10
         xs type: A