Remove accumulation fields' PERIOD from the restart file

[billsacks]

Description of changes

This doesn't need to be on the restart file, and having it read from the
restart file causes wrong behavior when changing the model time step.

See #1789 for details

Specific notes

Contributors other than yourself, if any:

CTSM Issues Fixed (include github issue #):
Resolves #1789

Are answers expected to change (and if so in what way)? YES - for any case where the time step differs from the one originally used to create the initial conditions file. This typically means changing answers for any case with a time step other than 1/2 hour.

Any User Interface Changes (namelist or namelist defaults changes)? No

Testing performed, if any: None yet; about to run test suite

[billsacks]

I have spent more time looking at the relevant code, with a particular focus on whether new problems / inconsistencies will arise from my proposed fix of removing the accumulation fields' period from the restart file (e.g., will there be problems because now we're using a newly-initialized period value, but still reading each accumulation field's nsteps from the restart file?). My overall conclusion is that there could be some weirdness at the start of a run, but at least for a startup or hybrid run, that weirdness should work itself out within about the first averaging period. A branch or restart run could have some longer-term potential weirdness, so for now I think we should recommend that people NOT change the time step on a branch or restart run. With (significant?) additional work, we could probably avoid this additional weirdness, but my feeling is that it isn't worth the effort right now. In any case, I feel like my proposed fix will bring things much closer to being correct than they currently are when changing the time step. More details below:

In extract_accum_field_timeavg, there is:

    if (mod(nstep,this%period) == 0) then

In a branch run, where nstep continues to accumulate, that is going to be weird when changing time steps, but I don't think it will be hugely problematic: I think things will work themselves out after one averaging period. The weirdest thing that might happen is that the averaging periods may no longer be aligned with day boundaries. I guess this argues for not changing the time step in a branch run, but using a hybrid or startup run instead.

There is similar potential weirdness in update_accum_field_timeavg. That includes some additional potential weirdness due to the use of this%nsteps:

    if (mod(nstep,this%period) == 0) then
       do k = begi,endi
          if (this%active(k)) then
             this%val(k,level) = this%val(k,level) / this%nsteps(k,level)
          end if
       end do
    end if

But it looks like this%nsteps should be reset to 0 (earlier in that subroutine) when nstep is 1, so as long as we're in a startup or hybrid case, I think this will be okay. If we're in a branch case (where nstep has continued from before), then there will be weirdness until we finish out the current accumulation period.

There is also weirdness of a different kind for runmean accumulation (in update_accum_field_runmean):

    do k = begi,endi
       if (this%active(k)) then
          kf = k - begi + 1
          this%nsteps(k,level) = this%nsteps(k,level) + 1
          ! Cap nsteps at 'period' - partly to avoid overflow, but also because it doesn't
          ! help us to accumulate nsteps beyond a value of 'period' (because nsteps is
          ! just used to determine accper, and accper needs to be capped at 'period'). A
          ! side-benefit of this capping of nsteps is that accper (the accumulation
          ! period) is always equal to nsteps.
          this%nsteps(k,level) = min(this%nsteps(k,level), this%period)
          accper = this%nsteps(k,level)
          this%val(k,level) = &
               ((accper-1)*this%val(k,level) + field(kf)) / accper
       end if
    end do

I think this will be okay when going to longer time steps (i.e., decreasing this%period), but when moving to shorter time steps (increasing this%period), the first part of the run will see too-small this%nsteps. This isn't a huge problem, but until we have gotten up to this%nsteps = this%period, each new time step's value will have a bigger influence on the running mean than it really should. It looks like this problem will exist in startup and hybrid runs as well as branch runs.

• We could probably fix this problem by allowing this%nsteps to get really big rather than capping it at this%period (and then capping the local accper instead), but I'm not sure it's worth making that change.

%nsteps will also be weird at first for a runaccum field. However, it looks like %nsteps is irrelevant for a runaccum field (i.e., it's never used for anything), so that shouldn't be an issue.