`getTimeStepNum` is wrong

In /utils there is a little function getTimeStepNum: https://github.com/terrapower/armi/blob/a857635c4f91147805117d57ac5fa3fa93374a1a/armi/utils/__init__.py#L79-L89

This function is buggy. For instance, consider an evenly-spaced cycle history defined in some cs with burnSteps: 3 nodalized as such:

If a user were to call getTimeStepNum(2, 2, cs), they would get 2*4 + 2 = 10, which is clearly incorrect. From my understanding, the answer should be 8.

It is also a bit ambiguous what should be returned by this function. Particularly on nodes that are at the beginning/end of a cycle. For instance, is an EOC node associated with the time step that came before, the time step that comes after (which is not clearly defined), or nothing at all?

Looking through the framework, it appears to only be used in a test for the historyTracker, which apparently isn’t even supported anyways. And then looking through our internal codes, I only see it being used one single time (in Crucible @sammiller11235 ).

So what do we want to do with this little bugger? I’m happy to make the changes myself as part of #637 , but don’t know exactly how to resolve it.

Personally I would advocate getting rid of it entirely and replacing it with a function more like getTimeNodeNum, which would be well defined.

[keckler]

Okay, I agree with that, thanks @sammiller11235 for making that clear.

I think then that it would make sense to change the name of this function so that its intent is more clear. Especially since the docstring also refers to "timestep"s, I think it should be clarified.

Any complaints on that approach? If not, I’ll go ahead and do it.

[sammiller11235]

I think this is actually functioning as intended, although the semantics of it could probably be improved. Because ARMI stores data at both the “EOC” and “BOC” as separate “nodes”, there is actually an additional index involved. In your figure above, you show (0,3) and (1,0) as the same thing, but in the ARMI database, these are two distinct “nodes”. Even though there was not a “burnStep” to go between the two, if you were simply indexing the number of storage locations in the ARMI database, there would be 10 indices (for (2,2)). The wording “timeStep” is the problem, as the time has not increased. It might be better described as “getNumberOfDatabaseIndices” or similar