Stop running 0th time step if possible, or at least clean up its handling in history output

[billsacks]

Within CESM, we run CTSM for an extra 0th timestep at the start of a simulation. If I remember correctly, this was done because of some need of CAM's that I either never understood or have forgotten.

I'm thinking that we should not do this when running CTSM via LILAC. This could be at least slightly important if you're trying to start at a very exact time for a short weather prediction run.

In fact, it's questionable whether we should still be doing this in CESM.

@mvertens do you agree that we should ideally change this behavior to avoid the 0th timestep when running with LILAC?

[(2020-07-14) I have removed this from the LILAC project because it is potentially a broader issue than just LILAC, but I am keeping a reference to it in that project.]

[mvertens]

@Bill Sacks <sacks@ucar.edu> - yes! I think getting rid of the 0th time step would be a really good thing to do.

…

On Wed, Feb 12, 2020 at 3:55 PM Bill Sacks ***@***.***> wrote: Within CESM, we run CTSM for an extra 0th timestep at the start of a simulation. If I remember correctly, this was done because of some need of CAM's that I either never understood or have forgotten. I'm thinking that we should *not* do this when running CTSM via LILAC. This could be at least slightly important if you're trying to start at a very exact time for a short weather prediction run. In fact, it's questionable whether we should still be doing this in CESM. @mvertens <https://github.com/mvertens> do you agree that we should ideally change this behavior to avoid the 0th timestep when running with LILAC? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#925?email_source=notifications&email_token=AB4XCE7RBOKR4WQJBJ76PM3RCR47BA5CNFSM4KUF6CKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INC7O3Q>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCE4KKZLAD2MFEP7P6RTRCR47BANCNFSM4KUF6CKA> .

[billsacks]

From a discussion yesterday - @mvertens thinks that the whole 0th timestep thing may be a historical artifact that should be removed even within CESM – but this probably needs a bit more analysis.

[billsacks]

If we don't completely remove the 0th time step, then we should at least fix history averaging / output to avoid the messy off-by-one issues that arise when doing non-monthly output: this 0th time step shifts all other history output and so makes the aggregation of history times non-intuitive.

[billsacks]

This came up again, and @mvertens expressed more certainty that the 0th time step is a historical artifact that should just be removed: it is a relic from when CLM was a subroutine call within CAM and CAM ran this 0th time step so CLM needed to as well. They kept it in place as they migrated CLM to its own component so that answers would stay the same across that migration, but that is far enough in the past that she feels it can (and should) be removed. It's unclear whether CAM needs to keep it or if the 0th time step can be removed on the CAM side, too, but it feels pretty clear that it can be removed on the CTSM side now.

[billsacks]

We have a number of uses of the function is_first_step, or equivalent direct checks of nstep == 0. From a quick look through the code, it looks like most of those checks should be removed once we tackle this issue, because they seem intended to check if it is this special time step 0. However, the following two uses seem to intend to check if this is the first time step of the run – and so should be changed to check if nstep == 1 (probably by changing the implementation of is_first_step):

• WaterStateType.F90: Restart subroutine
• clm_driver.F90: need_glacier_initialization

Update (2022-02-03): I just added one more check of is_first_step that should be backed out when we tackle this issue: see the changes in CNPhenology in dadbc62.

Update (2022-07-13) I noticed a check of nstep /= 0 in accumulMod that will also need some thought. I think when I did my earlier search I looked for nstep == 0 but didn't look for similar things like nstep /= 0, nstep > 0, nstep >= 1, etc. We'll need to check for uses like that.