You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A user ran 9982 years of a 3 degree ocean-ice run (the CORE forcing dataset covers 62 years, so this represents 161 cycles). They then tried to branch off the run for a couple of experiments, and ran into an illegal linear times issue when 9999-12-31 tried to roll over to 10000-01-01. (I believe he's using CESM 2.1, which is MCT-based rather than NUOPC-based, so the error message out of a recent beta tag might be different.)
Anyway, setting up a branch run instead of a hybrid is preferable because a hybrid run doesn't start the ocean component until the second coupling interval... so a branch would be a bit-for-bit continuation while a hybrid would change answers. However, he currently has to use a hybrid because the branch forces the user to keep the calendar from the run being continued.
While I could see an issue with creating a branch run B from the January 1st restart files from run A and trying to claim B starts in the middle of the year, a way to either reset the year to 0001 or set it to an arbitrary YYYY value while keeping the month and day constant would be helpful.
At a recent CSEG meeting, we discussed another option for supporting this use case: using 5 or 6 digits for the year instead of the current 4 digits. That seems more complicated than letting users branch from 9999 and reset the calendar back to 0001, and also has the potential for creating other issues (such as ESMCI/cime#2903).
The text was updated successfully, but these errors were encountered:
A user ran 9982 years of a 3 degree ocean-ice run (the CORE forcing dataset covers 62 years, so this represents 161 cycles). They then tried to branch off the run for a couple of experiments, and ran into an
illegal linear times
issue when 9999-12-31 tried to roll over to 10000-01-01. (I believe he's using CESM 2.1, which is MCT-based rather than NUOPC-based, so the error message out of a recent beta tag might be different.)Anyway, setting up a
branch
run instead of ahybrid
is preferable because a hybrid run doesn't start the ocean component until the second coupling interval... so a branch would be a bit-for-bit continuation while a hybrid would change answers. However, he currently has to use a hybrid because the branch forces the user to keep the calendar from the run being continued.While I could see an issue with creating a branch run B from the January 1st restart files from run A and trying to claim B starts in the middle of the year, a way to either reset the year to 0001 or set it to an arbitrary YYYY value while keeping the month and day constant would be helpful.
At a recent CSEG meeting, we discussed another option for supporting this use case: using 5 or 6 digits for the year instead of the current 4 digits. That seems more complicated than letting users branch from 9999 and reset the calendar back to 0001, and also has the potential for creating other issues (such as ESMCI/cime#2903).
The text was updated successfully, but these errors were encountered: