Open rsdunlapiv opened 2 years ago
@rsdunlapiv do you remember what branch is associated with this issue? Is it https://github.com/esmf-org/esmf/tree/newalarm? Thanks.
See also https://docs.google.com/document/d/1ZlI12Q8XPwQgPCuu1feyrUorhfuxkxhQMG50Iv97jU8/edit - sent by Arun Sept 14, 2023 with the note:
One key requirement as we look forward to Data Assimilation is being able to move the model forward and backward which will have some work to be done on the ESMF clock side of things. I am forwarding you a requirements document with the kinds of tests we would like to see the model pass.
Other related alarm tickets: https://github.com/esmf-org/esmf-support/issues/11, https://github.com/esmf-org/esmf-support/issues/15
recap meeting.. may need to update the branch to 8.7.
Dan said that Fei had tried it but we need to test out other places/systems. Action - give UFS team the branch to try out time management. (Ann to follow up in the next UFS meeting).
That this is NOT backward compatible and therefore need to move the branch to 9.0
That this is NOT backward compatible and therefore need to move the branch to 9.0
After a bit more discussion, we're not sure about this point. The key question is whether alarms are still sticky by default. Our initial thinking was that alarm stickiness is no longer supported, which would break backwards compatibility, but from further discussion, it seems like we're not sure about that point and it needs some further investigation.
Action: 1. look at the original issue.
Consideration: has a new alarm class to try it out. but may also need to consider clock.
Impact: NASA is still asking about this.
@rsdunlapiv - It would be good to have a description of the current status of this, and what the outstanding issues are before you leave.