CICE-Consortium/CICE

msec not allowed to be set to non-zero values for initial runs

zarzycki opened this issue · 4 comments

zarzycki commented

Code reference: https://github.com/CICE-Consortium/CICE/blob/766ff8d9606ae08bdd34ac2b36b6b068464c7e71/cicecore/drivers/nuopc/cmeps/ice_comp_nuopc.F90#L783C1-L786C1

In this block of code, is there a reason why msec is not initialized (well, set to something other than the default of 0)?

In CESM, I have found ESMF chokes with async clocks if START_TOD is not = 0 (e.g., a 12Z initialization of CAM-MPAS). I have gotten around this by modifying ice_comp_nuopc.F90:

          call abort_ice(subname//' :: ERROR idate lt zero')
       endif
       myear = (idate/10000)                     ! integer year of basedate
       mmonth= (idate-myear*10000)/100           ! integer month of basedate
       mday  =  idate-myear*10000-mmonth*100     ! day of month of basedate
!++CMZ
       msec = start_tod
!--CMZ

which alleviates the issue and synchronizes the clocks and permits the run to complete, but I'm not sure if there's a particular design choice to omit setting msec I am ignoring.

dabail10 commented

Thanks Colin. I guess we have not needed a time of day start time. This is a good suggestion and I will look to implement it.

dabail10 commented

Adding @DeniseWorthen to this one. How is UFS handling the curr_tod and start_tod?

anton-seaice commented

The suggested change looks correct, ACCESS don't use part days for anything much at this point, so we haven't had this issue.

DeniseWorthen commented

@dabail10 Let me look into this. We regularly run at non-zero start_tod values (hr=6 etc).

W/o looking at the code, I wonder if it is because we always have the _init times set in ice_in? So, for initial time of 06z, we have sec_init = 21600.