Use clearer input syntax for hexagonal lattice pitch

[mgjarrett]

What is the change?

Added an option for a user to specify a hexagonal pitch directly:

latticePitch: {hex: 1.5}

Why is the change being made?

Previously, a user had to specify the triangular pitch using the x attribute of latticePitch, which is confusing because the pitch is not necessarily equal to the x distance between two neighbors in a hex grid.

latticePitch: {x: 1.5}

https://github.com/terrapower/armi/blob/main/armi/reactor/grids/hexagonal.py#L152-L161

• Fix 1284 (fix for this issue pulled into a different PR, Fix some bugs in "corners up" Hex Grids #1649)
• Close Finding hexagonal pin pitch for wire-less assemblies #252

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify any new/changed code.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes have been updated if necessary.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in pyproject.toml.

[john-science]

I'm just thinking aloud here, but what something "flat-to-flat" be better for hex grids?

Isn't the goal to call out that we are going to be explicitly picking one over the other?

[mgjarrett]

I'm just thinking aloud here, but what something "flat-to-flat" be better for hex grids?

Isn't the goal to call out that we are going to be explicitly picking one over the other?

I'm not sure I understand what you are proposing. Do you mean specifying the pitch/flat-to-flat distance as flat-to-flat in the blueprints instead of latticePitch? I think latticePitch is still a fine descriptor of that parameter for a hexagonal lattice. And this allows us to not break any backwards compatibility with existing blueprints files, which would be an enormous pain.

[mgjarrett]

The bug fix was pulled out of this PR and into #1649

The remaining part of this PR is an optional/nice-to-have feature. It's just allowing users to define the hex pitch in blueprints in a slightly different way than before. No rush to push this through now, really.

[john-science]

The unit tests broke after my PR merged. Sorry!

[mgjarrett]

The unit tests broke after my PR merged. Sorry!

No worries! I just have to pull out what was moved over to #1649 and I think it will work.

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[john-science]

@mgjarrett Forgive me, I have totally lost where this PR was at. When you think it is ready for review, take it out of Draft mode.

[mgjarrett]

I think the PR is ready. For context, I was trying to address the issue that Drew and Mitch were discussing 3 years ago over on this issue #252:

[mgjarrett]

I had unintentionally added some files that were sitting around in my git directory to this PR. These files have been removed, so this PR is now ready.

[john-science]

@mgjarrett Does this PR require changes downstream? (Is it backwards compatible, or do we need to fix dozens of downstream input files after merging this PR?)

[john-science]

I was thinking it would be nice to show that this works for corners up and flats up.

I was think you could copy/paste this test, and just search/replace "geom: hex_corners_up" with "geom: hex.

Thoughts?