CDEPS send wrong nextsw_cday on the first timestep.

[mvdebolskiy]

trafficstars

When running CTSM with clm50cam7LndTuninMode testmod which sets user_nl_datm:

iradsw = -1
nextsw_cday_calc = "cam7"

The nextsw_cday on the first timestep is -1. Which is due to stepno > 0 in components/cdeps/datm/atm_comp_nuopc.F90:getNextRadCDay() :

    if (liradsw > 1) then
       delta_radsw = liradsw * dtime
       if (nextsw_cday_calc_cam7) then
          ! The logic in this block is consistent with the driver ordering in CAM7 and
          ! later. So this is appropriate when using cplhist forcings generated from CAM7
          ! or later.
          if (mod(tod,delta_radsw) == 0 .and. stepno > 0) then
             nextsw_cday = julday + 1*dtime/shr_const_cday
          else
             nextsw_cday = -1._r8
          end if
       else
          if (mod(tod+dtime,delta_radsw) == 0 .and. stepno > 0) then
             nextsw_cday = julday + 2*dtime/shr_const_cday
          else
             nextsw_cday = -1._r8
          end if
       end if
    else
       nextsw_cday = julday + dtime/shr_const_cday
    end if

However, what CAM7 does in radiation.F90 is different:

   radiation_nextsw_cday = -1._r8
   dosw   = .false.
   nstep  = get_nstep()
   dtime  = get_step_size()
   offset = 0
   do while (.not. dosw)
      nstep = nstep + 1
      offset = offset + dtime
      if (radiation_do('sw', nstep)) then
         radiation_nextsw_cday = get_curr_calday(offset=offset) 
         dosw = .true.
      end if
   end do
   if(radiation_nextsw_cday == -1._r8) then
      call endrun('error in radiation_nextsw_cday')
   end if

   ! determine if next radiation time-step not equal to next time-step
   if (get_nstep() >= 1) then
      caldayp1 = get_curr_calday(offset=int(dtime))
      if (caldayp1 /= radiation_nextsw_cday) radiation_nextsw_cday = -1._r8
   end if

Which actually results in the correct value at 0th timestep.

I am not sure how critical this is, however for Fates compsets with namelist changes in user_nl_datm (see above) this will result in error for errsol since ctsm5.3.034. ESCOMP/CTSM#3043 In addition, This issue means that on 0th timestep, non-sensical orbital parameters are passed and coszen is calculated wrongly. Most of the components don't do albedos/radiation on the 0th/first timestep, however, if there are routines that need coszen for other purposes, That might cause an issue.

[mvertens]

@mvdebolskiy - thanks for looking into this. This does look like a bug.

The very first nextsw_cday that datm calculates is in the InitializeRealize phase

    ! For nuopc - the component clock is advanced at the end of the time interval
    ! For these to match for now - need to advance nuopc one timestep ahead for
    ! shr_strdata time interpolation
    call ESMF_ClockGet( clock, currTime=currTime, timeStep=timeStep, advanceCount=stepno, rc=rc)

    nextsw_cday = getNextRadCDay(dayofYear, current_tod, stepno, idt, iradsw)

    call dshr_state_SetScalar(nextsw_cday, flds_scalar_index_nextsw_cday, exportState, flds_scalar_name, flds_scalar_num\
, rc)

where advanceCount is to set the number of times the ESMF_Clock has been advanced. So I think the right solution is if stepno is zero to set nextsw_cday to julday. @billsacks @mvdebolskiy - does that make sense?

[mvdebolskiy]

@mvertens I already have a fix. Will fire a PR here and to our fork today.

[billsacks]

Thanks a lot for digging into this @mvdebolskiy and @mvertens !

I don't understand the details of this well enough to be able to give an informed opinion, though could join a meeting to talk it through if that would be helpful. But I'm also happy to trust your findings on this if you have come to understand it.

Also pinging @adamrher and @olyson , who developed and tested the cam7 version of this, in case they have any input - or at least to keep them in the loop.

[mvertens]

@billsacks @mvdebolskiy - actually I think a quick call would be helpful. It sounds like there is already a PR https://github.com/ESCOMP/CTSM/pull/3051/files that takes care of this in CLM. There were real subtleties in putting the current logic into CDEPS for nextsw_cday - so I think we need to be careful in introducing new changes - particularly since CICE uses this value for G compsets - and its more than CLM that needs to be considered.

[mvdebolskiy]

@mvertens @billsacks I can do later today.

[mvertens]

Me also.

[billsacks]

I can do any time after 12 pm MDT today... but I realize that's getting late for you. I also have a lot of flexibility tomorrow if that would be better.

[mvdebolskiy]

12 pm MDT is ok for me (but not later). Tomorrow any time before 11 am MDT.