Recommendations for setting Reactor.p.time for calendar time?

[drewj-usnctech]

I can't seem to find anything inside the ARMI framework that sets the calendar time for a simulation. There's this Reactor.p.time parameter

armi/armi/reactor/reactorParameters.py

Lines 78 to 83 in 6603c1d

	pb.defParam(
	"time",
	units=units.YEARS,
	description="Time of reactor life from BOL to current time node",
	categories=["depletion"],
	)

with a depletion description

but it doesn't seem to be set inside ARMI. It looks like the cycle and node integers are serialized, but then something must set Reactor.p.time in order for it to be useful in e.g., report generation

armi/armi/physics/neutronics/reports.py

Line 98 in 6603c1d

report[NEUTRONICS_SECTION][KEFF_PLOT].add(labels[0], r.p.time, r.core.p.keff, None)

And it seems to me that this is something that the main Operator or a shipped interface could handle relatively easily? The Operator handles marching from (cycle, node) to (cycle, node), so it could conceivably also set Reactor.p.time

We have a kind of complex routine that re-constructs the time from the (cycle, node) value at interactEveryNode and it's got me thinking there's got to be a better way.

So the question(s) are

1. What is the recommended way to set Reactor.p.time in a depletion rune?
2. Is this something that ARMI could standardize such that the field is set as the simulation marches in time, prior to calls to Interface.interact*?

[keckler]

@drewj-usnctech Your analysis is spot-on. Check out this issue, it has some context that probably answers your question: #1100

Long story short, right now this time parameter is advanced by our internal depletion plugin. I don't think there is any particularly good reason for that.

[drewj-usnctech]

Thanks @keckler. Question isn't really answered, but I've got more threads to pull now

[john-science]

@keckler At some point, I would like to pick your brain about this.

[drewj-tp]

@john-science and I are looking into this

[john-science]

Notes.

That comes from here:

armi/armi/utils/__init__.py

Line 178 in ee691ab

def _getStepAndCycleLengths(cs):

The ARMI settings in questions: nCycles, cycleLengths. Both defined in ARMI. Though I think the setting step days is sometimes used.

For example:

armi/armi/tests/anl-afci-177/anl-afci-177.yaml

Lines 9 to 15 in ee691ab

	cycleLength: 411.11
	# end-section-1
	loadingFile: anl-afci-177-blueprints.yaml
	shuffleLogic: anl-afci-177-fuelManagement.py
	fuelHandlerName: SampleShuffler
	# end-section-2
	nCycles: 10

[john-science]

I think this requires a two-step approach:

1. Move the one line to set r.p.time into ARMI (at the VERY beginning of the time step).
2. Document this somewhere in the ARMI docs.

The (1) here will require some downstream testing.

[drewj-tp]

I think that's adequate. My preference would be that this is something the operator does before the interface stack restarts. That is, every interface knows r.p.time is set correctly

[john-science]

Okay, that's a fair improvement. We already do things like that in Operator:

armi/armi/operators/operator.py

Line 394 in 3431c44

self.r.p.timeNode = startingNode

armi/armi/operators/operator.py

Lines 427 to 431 in 3431c44

	def _timeNodeLoop(self, cycle, timeNode):
	"""Run the portion of the main loop that happens each subcycle."""
	self.r.p.timeNode = timeNode
	self.interactAllEveryNode(cycle, timeNode)
	self._performTightCoupling(cycle, timeNode)

Seems like we could find a good place for that.