Fix bug with alarms after clock direction change.

[TerribleNews]

I have been working on adjoint development for GCHP and found a problem with the history alarms after running the clock forward and then reversing it. It appears to be a problem with the checkRingTime command which is called in a for loop but changes a variable in the clock, userChangedDirection, which is then read in subsequent loop iterations but the original value has been overwritten. This small change saves the value and resets it before each call to checkRingTime so that the correct branch is taken in there, and then the last one sets clock->userChangedDirection to false, which should be the value after the loop has completed. This is probably not the most efficient fix, but it's the one that requires the smallest code change.

[sdeastham]

Can anyone from the ESMF team confirm if this bug is still present? It is unfortunately a major issue for an adjoint application being developed for the NASA GEOS ecosystem.

[danrosen25]

@sdeastham @TerribleNews
The ESMF Team is reworking the Time Manager and Alarm classes.
https://github.com/esmf-org/esmf/tree/newalarm
We're getting ready to test the above branch, which may fix the alarm bug discussed here. I'll make a note of this issue on the branch PR.

[sdeastham]

Thanks @danrosen25 ! I'll keep an eye on the new class, that's good to hear. @TerribleNews - any idea if the new alarm class would inherently fix this issue?