@apcraig - if the approach here is ok, Ill run some tests.

@apcraig - if the approach here is ok, Ill run some tests.

This looks good, lets keep moving it forward. If you can run the io test suite, that would be great (it requires netcdf and pio capability). If not, I'm happy to do that (or up to a full test suite on multiple compilers) on derecho, let me know if/how I can help.

Have you tested this within CMEPS to see if the date strings are still working?

Have you tested this within CMEPS to see if the date strings are still working?

It was a couple of months back, so ill make sure to retest this.

Shall I change it to 6 digit years as well? (@jedwards4b )
e.g.

        if(myear <= 9999) then
           write(lpointer_file,'(a,i4.4,a,i2.2,a,i2.2,a,i5.5)') '.',yr,'-',mon,'-',day,'-',time
        else if (myear <= 999999) then
           write(lpointer_file,'(a,i6.6,a,i2.2,a,i2.2,a,i5.5)') '.',yr,'-',mon,'-',day,'-',time
        endif

@apcraig - if the approach here is ok, Ill run some tests.

This looks good, lets keep moving it forward. If you can run the io test suite, that would be great (it requires netcdf and pio capability). If not, I'm happy to do that (or up to a full test suite on multiple compilers) on derecho, let me know if/how I can help.

I've been trying to run the io tests on the unchanged cice repository, and three tests with hdf5 and pio fail in the run step.

The error is:

 (ice_pio_init) nprocs     =           16
 (ice_pio_init) pio_iotype =            4
 (ice_pio_init) iotasks    =            4
 (ice_pio_init) baseroot   =            1
 (ice_pio_init) stride     =            4
 (ice_pio_init) nmode      =            0
 (ice_pio_init) create file ./history/iceh_ic.2005-01-01-00000.nc
  
 (abort_ice)ABORTED: 
 (abort_ice) called from ice_history_write.F90
 (abort_ice) line number          689
 (abort_ice) error = 
 (ice_pio_check)NetCDF: Problem with HDF5 dimscales., (ice_write_hist) ERROR: en
 ding pio definitions

If I manually set iotasks = 1 , then it runs ok.

@anton-seaice This looked familiar from a different context. See ufs-community/ufs-weather-model#2174 (comment) and the following comments.

I wasn't involved in this issue, I just remembered something to do with 'dismscales'.

Have you tested this within CMEPS to see if the date strings are still working?

It was a couple of months back, so ill make sure to retest this.

Shall I change it to 6 digit years as well? (@jedwards4b ) e.g.

        if(myear <= 9999) then
           write(lpointer_file,'(a,i4.4,a,i2.2,a,i2.2,a,i5.5)') '.',yr,'-',mon,'-',day,'-',time
        else if (myear <= 999999) then
           write(lpointer_file,'(a,i6.6,a,i2.2,a,i2.2,a,i5.5)') '.',yr,'-',mon,'-',day,'-',time
        endif

You mean the i6.6?

Thanks @DeniseWorthen - that is useful !

@apcraig - I guess you have run the io tests successfully on both intel-classic and oneapi ? Do you build with pnetcdf and hdf5 in one netcdf library? Or only pnetcdf for the cdf tests and only hdf5 for the hdf5 tests?

You mean the i6.6?

Yep

@dabail10 :

I reconfirmed default behaviour when using the CMEPS driver is unchanged, e.g. rpointer.ice.1959-01-01-10800 was made.

I did a second ad-hoc test, with
restart_pointer_append_date = .false.
set in nuopc.runconfig and then the file is just : rpointer.ice

@apcraig :

The io_suite results (on intel) are unaffected - results are bit for bit except for the hdf5 tests which failed before and after the change.

@dabail10 - have you been able to test this ?

Finally tested this in CESM. I'm going to look into it further, but the ice rpointer file does have the date while the other component restarts do not.

You just need to update your cesm to one new enough for the other components to have timestamps.

I am testing this in a cesm3_0_alpha7e sandbox. I thought this was already there?

It looks like you are using cdeps1.0.53 while the timestamps are in cdeps1.0.79

This doesn't make sense to me. I was using a cesm3_0_beta06 sandbox and the datestamps were working. This has cdeps1.0.73. My alpha7e sandbox (/glade/work/dbailey/cesm3_0_alpha07e) was using cdeps1.0.77. So, was it working before and then broken again?

@dabail10 I don't think that your sandbox is what you think that it is. You should be on a tag or on cesm3.0-alphabranch, but you are on branch master.

The code for this in other components is in CESM_share - https://github.com/ESCOMP/CESM_share/releases/tag/share1.1.9 or anything later is ok

Quick update here. The dates still have some bugs in the latest CESM tags. CDEPS, MOM, are still a work in progress. Anyhow, I tested this in a D compset (active CICE only) and was happy with the results.

Thanks @dabail10 ! - Please review/merge when ready @apcraig :)

I'll run some tests next week just to make sure all is OK and get it merged. Thanks all.

I ran a bunch of test on derecho and everything looks good, https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks#9933267b00849bdd7576a4abae8500edc99d31c4. Code also looks clean.

Merging now.