coupledIteration stored on data model is different than that used during the run

[keckler]

In the code chunk below, we store coupledIteration as n+1, whereas we send n into interactAllCOupled():

armi/armi/operators/operator.py

Lines 456 to 458 in eef58dd

	for coupledIteration in range(self.cs[CONF_TIGHT_COUPLING_MAX_ITERS]):
	self.r.core.p.coupledIteration = coupledIteration + 1
	converged = self.interactAllCoupled(coupledIteration)

This also means that the iteration number that is printed in the STDOUT is not aligned with the value used during interactCoupled() calls. In the screenshot below, the circled value comes from the DB.

armi/armi/operators/operator.py

Lines 568 to 573 in eef58dd

	if interactionName == "Coupled":
	cycleNodeInfo = (
	f" - timestep: cycle {self.r.p.cycle}, node {self.r.p.timeNode}, "
	f"year {'{0:.2f}'.format(self.r.p.time)} - iteration "
	f"{self.r.core.p.coupledIteration}"
	)

So basically, if anyone is trying to do something within an interactCoupled() call that is dependent on the iteration number, they are possibly using the wrong iteration number if they are using the STDOUT as their guide.

[keckler]

Looks like the CrossSectionGroupManager is assuming zero-indexing:

armi/armi/physics/neutronics/crossSectionGroupManager.py

Lines 938 to 972 in eef58dd

	def interactCoupled(self, iteration):
	"""Update cross-section groups on each physics coupling iteration to get latest
	temperatures.
	.. impl:: The lattice physics interface and cross-section group manager are connected
	during coupling.
	:id: I_ARMI_XSGM_FREQ3
	:implements: R_ARMI_XSGM_FREQ
	This method updates representative blocks and block burnups at every node and the first
	coupled iteration for each cross-section ID if the control logic for lattices physics
	frequency updates is set for the first coupled iteration (``firstCoupledIteration``)
	through the
	:py:class:`LatticePhysicsInterface <armi.physics.neutronics.latticePhysics>`.
	The cross-section group manager will construct representative blocks for each
	cross-section ID at the first iteration of every time node.
	Notes
	-----
	Updating the cross-section on only the first (i.e., iteration == 0) timenode can be a
	reasonable approximation to get new cross sections with some temperature updates but not
	have to run lattice physics on each coupled iteration. If the user desires to have the
	cross sections updated with every coupling iteration, the ``latticePhysicsFrequency: all``
	option.
	See Also
	--------
	:py:meth:`~armi.physics.neutronics.latticePhysics.latticePhysics.LatticePhysicsInterface.interactCoupled`
	"""
	if (
	iteration == 0
	and self._latticePhysicsFrequency
	== LatticePhysicsFrequency.firstCoupledIteration
	) or self._latticePhysicsFrequency == LatticePhysicsFrequency.all:
	self.createRepresentativeBlocks()

[keckler]

The LatticePhysicsInterface also assumes zero-indexing:

armi/armi/physics/neutronics/latticePhysics/latticePhysicsInterface.py

Lines 224 to 257 in eef58dd

	def interactCoupled(self, iteration):
	"""
	Runs on coupled iterations to generate cross sections that are updated with the temperature state.
	Notes
	-----
	This accounts for changes in cross section data due to temperature changes, which are important
	for cross section resonance effects and accurately characterizing Doppler constant and coefficient
	evaluations. For Standard and Equilibrium run types, this coupling iteration is limited to when the
	time node is equal to zero. The validity of this assumption lies in the expectation that these runs
	have consistent power, flow, and temperature conditions at all time nodes. For Snapshot run types,
	this assumption, in general, is invalidated as the requested reactor state may sufficiently differ
	from what exists on the database and where tight coupling is needed to capture temperature effects.
	.. warning::
	For Standard and Equilibrium run types, if the reactor power, flow, and/or temperature state
	is expected to vary over the lifetime of the simulation, as could be the case with
	:ref:`detailed cycle histories <cycle-history>`, a custom subclass should be considered.
	Parameters
	----------
	iteration : int
	This is unused since cross sections are generated on a per-cycle basis.
	"""
	# always run for snapshots to account for temp effect of different flow or power statepoint
	targetFrequency = (
	LatticePhysicsFrequency.firstCoupledIteration
	if iteration == 0
	else LatticePhysicsFrequency.all
	)
	if self._latticePhysicsFrequency >= targetFrequency:
	self.r.core.lib = None
	self.updateXSLibrary(self.r.p.cycle, self.r.p.timeNode)

[keckler]

I'm not sure that anything important is actually broken here, so I removed the "bug" label. But I'd say this is confusing and I would advocate that the value used and the value printed are aligned with each other.

[keckler]

The "Tight Coupling Convergence Summary" table is also zero-indexed:

So it really seems like everything except for the interaction hook header is zero-indexed. Seems like an easy fix to just change the headers.