variable orbital year is not working on restarts

[mvertens]

This can be seen with the following test: ERS_Ld6_Vnuopc.f10_f10_musgs.IHistClm50SpRsGs.cheyenne_intel.clm-decStart The original values of the orbital settings are:

     orb_eccen = 1.e36
     orb_iyear = 1850
     orb_iyear_align = 1850
     orb_mode = variable_year
     orb_mvelp = 1.e36
     orb_obliq = 1.e36

When the are set to the following - the above tests works.

orb_eccen = 1.e36
orb_iyear = 2000
orb_iyear_align = 2000
orb_mode = 'fixed_year'
orb_mvelp = 1.e36
orb_obliq = 1.e36

The issue is that the orbital parameters in mct are updated in the driver - but there is no corresponding analogy for what needs to be done in CMEPS. So the solution should be that each component must update its orbital values independently give a driver settings the above.

[billsacks]

Discussion with @mvertens - we aren't sure if this is still an issue. What's easy with NUOPC is to transfer scalars in initialization via ESMF attributes (e.g., that was done to fix the DAE test). The problem is exchanging time-varying scalar data (e.g., that one component sets and the others need). We have a way to exchange scalar field data (no distributed dimension; just an undistributed dimension); that's the way nextsw is sent.

At this point, every cap reads its own orbital values, so this might need to be done in the cap level. It's possible that we could use a scheme similar to nextsw... not sure about this.

[billsacks]

@mvertens @jedwards4b @briandobbins - We should determine if this is still an issue; if so, it feels important to resolve for CESM3.

[billsacks]

@mvertens do you remember enough about this to be able to say what I could look at (e.g., in the code) to determine if this has been fixed properly? e.g., should I look for some updating of orbital values in the various component caps?

[jedwards4b]

@billsacks I think that this is fixed - can you confirm with the test ERS_Ld6_Vnuopc.f10_f10_musgs.IHistClm50SpRsGs.cheyenne_intel.clm-decStart

[billsacks]

Thanks @jedwards4b . I see that there are a variety of similar tests in the aux_clm test suite that are passing. And I see that @mvertens fixed CTSM in ctsm1.0.dev086... the relevant part of the ChangeLog says:

    Now each component NUOPC cap needs to compute possibly time varying
    orbital parameters. Before, in cpl7, this was done in the driver and
    passed to the components via seq_infodata. However, now the driver is
    really just a simple ascii file - so those calculations needed to
    migrate to the component caps.

I'm a bit concerned that I see "*_orbital_update" routines in some but not all components. These appear in pop, cdeps, cmeps (ocnalb_mod), cam, cice5, and clm; but I don't see similarly-named routines in other components such as cice6 or mom. Maybe the functionality is there but named something else, or maybe it still needs to be added? I can look a bit more into this when I get back from vacation the week after next if others aren't sure.

[klindsay28]

At this point, it doesn't look like MOM6 needs orbital parameters, so I don't find it surprising to not see calls to orbital routines in MOM6. (There are calls to FMS routines for cosz, but these are only present in offline tracer transport code.)

POP needed orbital parameters in order to get cosine zenith angle (coszen), which was used to scale shortwave by cozen when using daily coupling. I.e., we wanted to approximate the diurnal cycle of shortwave when it wasn't resolved with high enough frequency coupling. I think we ran in this mode in CESM1. I think we switched to hourly coupling in CESM2 and didn't need to invoke the cosz computations. We're not running MOM6 with daily coupling and simultaneously wanting to approximate the diurnal cycle of shortwave, so the use case that led to needing orbital parameters in POP isn't present in MOM6.

On Fri, May 24, 2024 at 4:27 PM Bill Sacks @.***> wrote:

Thanks @jedwards4b https://github.com/jedwards4b . I see that there are a variety of similar tests in the aux_clm test suite that are passing. And I see that @mvertens https://github.com/mvertens fixed CTSM in ctsm1.0.dev086... the relevant part of the ChangeLog says:

Now each component NUOPC cap needs to compute possibly time varying
orbital parameters. Before, in cpl7, this was done in the driver and
passed to the components via seq_infodata. However, now the driver is
really just a simple ascii file - so those calculations needed to
migrate to the component caps.

I'm a bit concerned that I see "*_orbital_update" routines in some but not all components. These appear in pop, cdeps, cmeps (ocnalb_mod), cam, cice5, and clm; but I don't see similarly-named routines in other components such as cice6 or mom. Maybe the functionality is there but named something else, or maybe it still needs to be added? I can look a bit more into this when I get back from vacation the week after next if others aren't sure.

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CMEPS/issues/44#issuecomment-2130447072, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADWZPO2KLAPEZVOICFWQMYTZD65GBAVCNFSM4KEL3YFKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGA2DINZQG4ZA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[billsacks]

Good to know @klindsay28 - thank you!

[jedwards4b]

We may want to ask @dabail10 about cice6.

[dabail10]

We use the orbital parameters in the CICE cap.

   call NUOPC_CompAttributeGet(gcomp, name="orb_iyear", value=cvalue, rc=rc)
   if (chkerr(rc,__LINE__,u_FILE_u)) return
   read(cvalue,*) orb_iyear
   call NUOPC_CompAttributeGet(gcomp, name="orb_iyear_align", value=cvalue, rc=rc)
   if (chkerr(rc,__LINE__,u_FILE_u)) return
   read(cvalue,*) orb_iyear_align

[billsacks]

@dabail10 - thanks. I see now that CICE6 doesn't have an ice_orbital_update, but calls ice_orbital_init every time step, with a first_time logic, and it looks like this does the same thing as is done in other components' orbital_update routines. So this looks good to go.

So it seems like this has probably been implemented in all components that need it. I'll run an ERS BHIST test (or equivalent) with a decStart testmod using the latest components after beta18 is made to confirm that this is working now.

[billsacks]

I have run an ERS BLTHIST test with a December start, crossing the year boundary, and it passes exact restart after bringing in @mvertens 's recent DGLC restart fix. That gives me a fair amount of confidence that variable orbital year is restarting correctly. See https://github.com/ESCOMP/CESM/pull/284 for details.