Cleaning up the codeTiming reports

[john-science]

What is the change? Why is it being made?

This is a cleanup of the code timing reports.

In short, I removed the columns "is active" and "time since" and changed the name of one column from "pauses" to "num iterations".

I also did some basic code cleanup, added some docstrings, and added some unit tests.

Note

Per Tony's request, this PR has a small API change that I will have to fix downstream.

SCR Information

Change Type: trivial

One-Sentence Description: Cleaning up the codeTiming reports.

One-line Impact on Requirements: NA

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify any new/changed code.
• The documentation is still up-to-date in the doc folder.
• The code style follows good practices.
• The dependencies are still up-to-date in pyproject.toml.

[opotowsky]

Unsolicited PR review and approval

[albeanth]

Thanks @john-science !

[albeanth]

Thoughts on replacing this

armi/armi/operators/operator.py

Line 506 in 904f06c

with self.timer.getTimer(interactionMessage):

with

with self.timer.getTimer(f"{interface.name}, {interactionName}, {cycleNodeTag}"):

?

[john-science]

...
with self.timer.getTimer(f"{interface.name}, {interactionName}, {cycleNodeTag}"):
...

Well, right now the message is:

            interactionMessage = " {} interacting with {} ".format(
                interactionName, interface.name
            )

And I'm not sure I like "interacting with". I was thinking something more like:

f"{interface.name}.{interactionName}()"

would be nicer, e.g.: GlobalFluxInterface.interactBOL(), FuelHandlerInterface.interactEveryNode(), etc.

But I think if we put "cycleNodeTag" in there it would break the timer reports. The "average" and "cummulative" columns for these calls would be broken.

[albeanth]

But I think if we put "cycleNodeTag" in there it would break the timer reports. The "average" and "cummulative" columns for these calls would be broken.

Not sure I follow how the average and cumulative would be broken. Wouldn't the timers just be separated out by cycle and time node? So if we have 1 cycle and 2 time nodes for a simulation, it would go from something like

TIMER REPORTS	CUMULATIVE (s)	AVERAGE (s)	NUM ITERS
GlobalFluxInterface.interactEveryNode	100	50	2

to something like

TIMER REPORTS	CUMULATIVE (s)	AVERAGE (s)	NUM ITERS
GlobalFluxInterface, interactEveryNode, c0n0	50	50	1
GlobalFluxInterface, interactEveryNode, c0n1	50	50	1

[albeanth]

with

with self.timer.getTimer(f"{interface.name}, {interactionName}, {cycleNodeTag}"):

?

I'd change this to be

with self.timer.getTimer(f"{interface.name}, {interactionName}, c{self.r.p.cycle}n{self.r.p.timeNode}"):

that won't separate out iters for interactCoupled, but I think it's ok to show those with numIters > 1

[john-science]

TIMER REPORTS CUMULATIVE (s) AVERAGE (s) NUM ITERS
GlobalFluxInterface, interactEveryNode, c0n0 50 50 1
GlobalFluxInterface, interactEveryNode, c0n1 50 50 1

Tight.... so why have the average/cumm/iters columns if everything is by cycle and node? For a 6-cycle run with dozens of time nodes, it'll be a lot harder to read the final table and see what percentage of the run was due to... some particular interface.

And, I think, that is what Mark wants. He wants to be able to look at an interface line and the new "total time" on the bottom, and get a rough estimate at a glance of what percentage of the run was due to a particular interface. (I am like 95% on this.)

[albeanth]

Tight.... so why have the average/cumm/iters columns if everything is by cycle and node?

In the example I gave where there is an even split, there's is arguably no utility. But, if one cycle/timenode takes way longer than another, there's arguably utility. But there's also a timer report at EOC so there's at least some breakup between cycles.

I would settle for

TIMER REPORTS	CUMULATIVE (s)	AVERAGE (s)	NUM ITERS
GlobalFluxInterface.interactEveryNode	100	50	2

though. I won't put my foot down on splitting by cycle time node.