Make timesteps easier to search for in log file
Closed this issue · 18 comments
This is a double request, I guess. We can split the ticket if need be.
I often want a quick way to find which timestep I'm in during a sim, but it's a little hard to search for. Here's one example:
=========== 08 - criticalCrIteration EveryNode - cycle 1, node 0 ===========
I can search for a few === signs to get to the last interface step to hit the log file, but there's no consistent way for me to search for the timestep. (cycle isn't the best search term). So we could get a creative about a universal way to get the timestep. But that is complicated by my next request, that the tight coupling iterations also display their timestep. Right now, they don't:
=========== 08 - criticalCrIteration Coupled - iteration 0 ===========
So I have to page up quite a bit if I'm, e.g., in the 7th coupled iteration to get the the last timestep displayed.
Here is a possible suggestion (timestep or timenode or any other word could be used):
=========== 08 - criticalCrIteration EveryNode - timestep: cycle 1, node 0 ===========
=========== 08 - criticalCrIteration Coupled - timestep: cycle 1, node 0 - iteration 0 ===========
@albeanth I seem to have a vague memory of you saying the second part of this request was either hard or impossible. Do you remember / can you give John a heads up on that?
+1 on the coupled iteration portion
it's possible. it just requires an API change on operator.py
which I'm fine with, but sometimes people get wigged out with API changes 🤷
No API promises until v1.0 😉
What would you all like the time steps to look like?
What would you all like the time steps to look like?
I don't have any strong feelings on this. I just would like to know there's a consistent way to search for the timestep.
@opotowsky I think you should add your suggestion for what this "should" look like to the ticket description. It's a good idea, and a really easy ticket for someone to take, once we fill in the detail. :)
I repeat: I have no strong opinions here (I know how fiery this stuff can get). But here is a possible suggestion (timestep or timenode or any other word could be used):
=========== 08 - criticalCrIteration EveryNode - timestep: cycle 1, node 0 ===========
=========== 08 - criticalCrIteration Coupled - timestep: cycle 1, node 0 - iteration 0 ===========
Oops, I see your comment. Adding to description. I'm only shy about adding a suggestion because folks get wild when vocab gets argued about!
@opotowsky If you want to go ahead with this change, you have broad group agreement. :)
Nice! I'll put it on my list 🎉
I agree with this @opotowsky, I think I asked @albeanth to do this when we started to use coupled iterations in a code review somewhere 😉
Edit: I think the change just needs to occur in _expandCycleAndTimeNodeArgs
@albeanth didn't do it before because there's an API update associated and he got push back. But we have a system now that should prevent anyone from being inconvenienced by an API change.
@opotowsky, @john-science - As I am looking at the open PR, I'm wondering now if we should also add anything about the reactors current "time" in the simulation as well. Cycle and Time node are great, but deciphering the cycle and node relationship to time step and cycle length could be helpful to users. @keckler I'm curious if this would helpful for you in multi cycle benchmarks like FFTF and EBR-II.
@opotowsky, @john-science - As I am looking at the open PR, I'm wondering now if we should also add anything about the reactors current "time" in the simulation as well. Cycle and Time node are great, but deciphering the cycle and node relationship to time step and cycle length could be helpful to users. @keckler I'm curious if this would helpful for you in multi cycle benchmarks like FFTF and EBR-II.
@jakehader what are you envisioning? I could see this getting tricky with detailed cycle histories. But could be useful, certainly. Would the day counter reset for each cycle? Or would it be a lifetime measure? Likewise, it might be useful to have an assembly param (or series of params) that states how long it has resided in a given system (e.g., Core, SFP, etc).
(either way, I think this is borderline scope creep for this particular Issue and should get moved to its own Discussion thread)
Probably scope creep. Nevermind
Probably scope creep. Nevermind
I do think it's an interesting idea though! We should chat more if you think it's worthwhile
@jakehader Yes! Make a new Discussion for that!
Adding the time (both within a cycle and within the reactor lifetime) would be very very useful, and it would not be difficult at all. Most of what you would need already exists here: https://github.com/terrapower/armi/blob/main/armi/utils/__init__.py