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

[onufer]

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]

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

[jakehader]

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

[onufer]

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]

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]

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]

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

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]

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]

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]

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

I certainly like the idea, and will try to find a way to make it happen.

Cons

The only "con" here is that it would break our round-tripping.

The answer might have to be that we provide and YAML linting tool through ARMI. And if you don't run your YAML file through the linter before you put it in ARMI, THEN we won't be round-tripping your YAML correctly.

Pros and More

• It would obviously be easier to read.
• The request is actually only for blocks in an assembly, so a more general solution is not being requested.