Pathway to ARMI 1.0.0

[john-science]

At time of writing, ARMI has a well-tested, stable codebase at version 0.3.0. But @keckler recently asked me what it would take to get ARMI to version 1.0.0. And that's a great question!

Obviously, I have a lot of ideas, but I think it's worth thinking through and getting some feedback from the userbase about the plan, before I re-publish the ARMI Roadmap, which is getting a little old, and I would like to reframe it to this 1.0.0 question.

Here is an interesting place to look for ideas.

v0.3.0

Published 2024-02-02

v0.4.0

September-ish timeline

The focus of this release will be paying off our technical debt. Though some new features are in the works, most notably in assembly axial expansion and more detailed modeling of fuel pins.

Must Have

• HexGrid work
  • Location of pins in tips-up hexagonal grid is off by 60 degrees (1-2 Days)
  • Incorrect pitch for tips up sub-block pin grid (1-3 days)
• Reduce the trickiness of ArmiObject.setNumberDensities() by moving it to Component (1-3 days)
• ArmiObject has many, ultra-specific methods. Try to clean house.
• Move the lattice physics modules out of ARMI (1-5 days)
• Move the crossSectionGroupManager out of ARMI
• Make EOC available in the DB (1-5 days)
• Axial Expansion with Multiple Pin Types
• Make the Doppler constant param VOLUME_INTEGRATED
• Inherit XS Settings when creating a new XS ID
• Move dochelpers.py out of ARMI and into the /doc/ directory

Should Have

• Get code coverage over 90%. (0-5 days)
• Move Global Nuclides to something not global (1-10 days)
• Remove the Operator from the Reactor (1-3 days)

Nice-to Have

• Redesign of migration scripts
• Improve High-Level ARMI Introduction
• Rename powerMultiplier to symmetryFactor (1-2 days)

v1.0.0

No firm timeline.

This is the big one. This release is meant to be the line in the sand where ARMI's API is finally stable, and ARMI is feature rich without including too much science or engineering within ARMI.

Features

• Some support for ex-core systems
• materials package re-design

Architecture

• Finish removing all the globals we want to remove

Quality Assurance

• Choose a type system: type hints, or NumPy docs or other

User Interface

• Improved user experience with preparing input files and analyzing output files is desired, possibly along the lines of e.g. NEAMS Workbench or with a web-based interface.

Plugin Ecosystem

• We want to finish the ARMI OpenMC plugin.
• We'd love to see an ARMI input model of BEAVRS benchmark (Modeling ex-core structures: RPV, shielding, etc. #262).
• We'd like to see an ARMI plugin related to INL's Deep Lynx.

[john-science]

@sombrereau @jeffbaylor @keckler @drewj-usnctech @opotowsky Just FYI. I am hoping to discuss this with all of you.

[dpham-materials]

I don't know if this belongs here, and I'm definitely not as familiar with the ARMI ecosystem, but the /materials/ folder could use some cleanup. From my newbie's glance, I can't tell what's being used and the essential properties for each type of material. The test coverage also looks a bit lacking.

[john-science]

Good point, David. I will put "materials package rework" on version 1.0.0, but hopefully we can get to it sooner than that.

[tp-pbritt-nuc]

Version 1.0.0 just denotes that it's past beta, correct?

I don't have any specific wants/needs. I would just say the "90% code coverage" is what I'd be looking for - make sure it works well enough to take to 1.0.0. As long as Pylot works, I'm not particular.

[john-science]

Well, let's not worry about terms like "alpha" and "beta" releases here. Let's see this more as a way to Plan for what's Important.

Though I would like to knock all of ARMIs sharp edges off by the 1.0.0 release.

[drewj-usnctech]

Exciting! Okay, I have a frustrating "it depends" type answer: what does a 1.0.0 mean?

Does it imply stability in the framework and/or API to a reasonably degree such that there's some (implicit or explicit) compatibility promises? E.g., Applications that work with 1.0.0 will work with 1.0.X and 1.X.Y but not 2.X.Y?

Does it mean it's mostly got everything you'd want a reactor modeling framework to support? If that's the case, I would toss these items in the bucket

• Modeling ex-core structures: RPV, shielding, etc. #262
• Make standard way to represent TRISO fuel #228
• Location of pins in tips-up hexagonal grid is off by 60 degrees #1278
• Incorrect pitch for tips up sub-block pin grid #1284

With these items, you can conceivably model the majority of reactor concepts in the wild. Or at least get close enough to be frustrated that ARMI gets close but not all the way

There is also this from the ARMI docs

We use the common major.minor.bump version scheme where a version string might look like 0.1.7, 1.0.0, or 12.3.123. Each number has a specific meaning:

major - Revved for DOE/NRC-sanctioned release or at the end of a long development cycle.

minor - Revved when we decide the code or our API has reached a stable point.

bump - Revved every time we modify the API, and any other time we want.

Type hints: yes please but maybe not required for 1.0.0 maybe before maybe later? There is a frustrating amount of double effort both doing type hints and numpydocs. This is a broader python pain point, but at least newer versions of sphinx are getting better at incorporating type hints?

[john-science]

I love it. I'm really excited to pick some targets and work towards them. I am also excited to see what the user base wants most.

major - Revved for DOE/NRC-sanctioned release or at the end of a long development cycle.

Yeah, this is an interesting point, because we are releasing ARMI to the NRC at version 0.3.0. Mostly because I think there is still some work to do. I am not sure if I will updates the docs on that point or not.

There is a frustrating amount of double effort both doing type hints and numpydocs.

Ugh. I am not really interested in duplicating effort. ARMI will go to "only type hints" or "only NumPy docs". But I doubt we will support both, in 1.0.0.

[opotowsky]

I'm team numpy docs for 1.0!

[albeanth]

I'm team type hints! 🥊

[tp-pbritt-nuc]

I'm team whatever-helps-me-navigate-the-type-nightmare-that-is-python....

[drewj-usnctech]

Made a poll for type hints - #1635

[mgjarrett]

Here are a couple open PRs that should go in by v0.4.0:

#1659
#1653

[mgjarrett]

Also #1654, or at least part of it. It does two things:

1. fix a bug in "corners up" hex lattice pitch calculation
2. introduce a new way for specifying hex pitch in the blueprints: latticePitch: {hex: 1.0}

We might consider splitting that into two PRs; we would want (1) in ASAP because it's a bug fix. (2) is just an enhancement without an immediate motivating need, so it could wait if we want to avoid it for now.

[john-science]

The results of this conversation have been officially moved to the ARMI Roadmap.