Fix tight coupling on lattice interface for Snapshots

[albeanth]

Description

For tight coupling, setting the requirement that cross sections be regenerated only when timeNode == 0 was made with only Standard run types with constant power, flow, and/or temperature in mind. When doing snapshot runs with tight coupling, this assumption becomes invalid and it is desirable to always regenerate cross sections. This PR addresses this and modifies the unit testing for the lattice physics interface to test for this.

The unit tests within the lattice physics interface were also somewhat lacking. So some additional unit tests were added to get the coverage up.

A few slight edits to documentations were also added.

---

Checklist

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

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

• The release notes (location doc/release/0.X.rst) are up-to-date with any bug fixes or new features.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in setup.py.

[albeanth]

@onufer @jakehader a heads up.

[mgjarrett]

We're adding this because we're using snapshots to reload from a given statepoint and then run at a different power/flow/temperature condition from the original case.

For now, we are still only updating XS at time node 0 for standard runs because the assumption is that a standard run will have similar power/flow/temperature conditions at all time nodes. This is not necessarily true. With detailed cycle histories, one could burn a reactor at 100% power / 100% flow for 50 days, then drop to 50% power / 50% flow and burn for another 50 days, then drop to 5% power / 20% flow and burn 10 days, etc. If we were to deviate far from the power/flow ratio = 1.0, we would likely want to update XS.

It feels like this caveat above should be documented somewhere, but I don't know the best place. Could be the docstring for this interactCoupled, or the user docs for tight coupling (or both).

[keckler]

What @mgjarrett said about varying power levels in a cycle is incredibly important for the user to understand, and is probably something we need to add better treatment for.

[albeanth]

For now, we are still only updating XS at time node 0 for standard runs because the assumption is that a standard run will have similar power/flow/temperature conditions at all time nodes. This is not necessarily true. With detailed cycle histories, one could burn a reactor at 100% power / 100% flow for 50 days, then drop to 50% power / 50% flow and burn for another 50 days, then drop to 5% power / 20% flow and burn 10 days, etc. If we were to deviate far from the power/flow ratio = 1.0, we would likely want to update XS.

This is an excellent point. I think it would be a worthy feature request in an issue.

It feels like this caveat above should be documented somewhere, but I don't know the best place. Could be the docstring for this interactCoupled, or the user docs for tight coupling (or both).

@jhader and I attempted to provide high-level justification for the time node == 0 case in the docstring for interactCoupled when the method was introduced. We could probably be more precise by calling out the expectation of consistent hot full power. Ironically, the tight coupling documentation directly contradicts this and shows the cross sections being updated at each time step.

[keckler]

We can put a warning here: https://terrapower.github.io/armi/user/inputs/settings.html#cycle-history

[albeanth]

Looks like we're getting a massive drop in coverage for latticePhysicsInterface. I think this is due to simply removing the call to loadTestReactor. So the drop may not actually be all that bad... The unit tests for the latticePhysicsInterface prior to this PR were very bare.

I will investigate, but I think we have two options:

1. bring back loadTestReactor . Which is a bit unnecessary since we don't need a full reactor for the existing interface tests and gives a bit of false coverage, in my opinion.
2. Add a bunch of dedicated unit tests for latticePhysicsInterface. That can either be in this PR or a separate PR.

@john-science do you have a preference?

[albeanth]

Looks like we're getting a massive drop in coverage for latticePhysicsInterface. I think this is due to simply removing the call to loadTestReactor. So the drop may not actually be all that bad... The unit tests for the latticePhysicsInterface prior to this PR were very bare....

I went with option 2. See 9eb5844. Coverage looks to be fixed. Locally, I am seeing coverage for latticeInterface.py on main reporting 48% and this PR upping that to 56%.

[albeanth]

@mgjarrett @keckler - I added a couple of commits reflecting your input on the clarity of the docstring and adding a note to the detailed cycle history docs.
af765f4
78547da