Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zarzycki opened this issue Jul 11, 2023 · 7 comments
Open

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

zarzycki opened this issue Jul 11, 2023 · 7 comments
Assignees

Comments

@zarzycki
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

dabail10 commented Jul 5, 2024

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

@anton-seaice
Copy link
Contributor

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
Copy link
Contributor

@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.

@dabail10
Copy link
Contributor

Finally circling back to this. I just had another request from the CAM developers. I think we want to listen to the driver on this and not the namelist. I will implement and test Colin's suggested fix.

@dabail10
Copy link
Contributor

@zarzycki does this change also work with RUN_REFTOD?

@zarzycki
Copy link
Author

I cannot say I recall trying a mid-day hybrid/branch run, which I think is needed to exercise RUN_REFTOD.

I would assume it should behave similarly since I think CAM is initialized in the same way, but I cannot 100% confirm it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants