how to change diagnostics starting time in diag_table?

[junwang-noaa]

Hello, We are setting up an IAU test. It is a restart run from the previous cycle. Now we want all the diagnostic fields especially those averaged or accumulated fields start to accumulate at a later forecast hour, in other words, not the model starting time. Currently in my diag_table I have:

20161003.00Z.C96.64bit.non-mono
2016 10 03 00 0 0

2016103000 is the starting time, the model restarts at fh=3, and I want all the averaged fields starts to accumulate at fh=6. Should I change the second line to 2016100306 in my case? e.g.

20161003.00Z.C96.64bit.non-mono
2016 10 03 06 0 0

I hope with this change the following two files:

"ocn%4yr%2mo%2dy%2hr",      6,  "hours", 1, "hours", "time", 6, "hours", "1901 1 1 0 0 0"
"SST%4yr%2mo%2dy",      1,  "days",  1, "days",  "time", 1, "days",  "1901 1 1 0 0 0"

will give me 6 hourly diagnostic fields (e.g. 2016100306-2016100312) in ocn files and daily diagnostic fields (2016100306-2016100406) for SST files even though the model starting time is 2016100300 and restarts at fh=03 (2016100303). Thanks.

[bensonr]

@thomas-robinson @uramirez8707 - can you guys help out here?

[uramirez8707]

sorry @junwang-noaa my fix is still not ready. Even though the time_bnds are correct [3, 9], it is still using data from hour 0 to hour 9. I need to work on this some more.

[junwang-noaa]

@uramirez8707 Thanks for letting me know!

[uramirez8707]

The fix is ready to be tested:
#1381

[junwang-noaa]

@uramirez8707 Thanks, I am working with nceplibs team to build the library. Will let you know what we get (hera is down today).

[junwang-noaa]

@uramirez8707 is your branch based on fms 2023.02? I am compiling the UFS weather model with your fms branch, but got error:

/scratch1/NCEPDEV/nems/Jun.Wang/nems/vlab/20230817/ufs-weather-model/FV3/atmos_cubed_sphere/model/multi_gases.F90(45): error #6580: Name in only-list does not exist or is not accessible.   [OPEN_NAMELIST_FILE]
      use fms_mod,           only: check_nml_error, open_namelist_file, close_file
----------------------------------------------------^
/scratch1/NCEPDEV/nems/Jun.Wang/nems/vlab/20230817/ufs-weather-model/FV3/atmos_cubed_sphere/model/multi_gases.F90(45): error #6580: Name in only-list does not exist or is not accessible.   [CLOSE_FILE]
      use fms_mod,           only: check_nml_error, open_namelist_file, close_file
------------------------------------------------------------------------^
compilation aborted for /scratch1/NCEPDEV/nems/Jun.Wang/nems/vlab/20230817/ufs-weather-model/FV3/atmos_cubed_sphere/model/multi_gases.F90 (code 1)
make[2]: *** [FV3/atmos_cubed_sphere/CMakeFiles/fv3.dir/model/multi_gases.F90.o] Error 1

Then I added "-Duse_deprecated_io" to compile the dycore code, but still got the same error message. Do we need to build when compile FMS? Thanks for your help!

[bensonr]

@junwang-noaa - there is a PR into GFDL_atmos_cubed_sphere with updates for the dev/emc branch of GFDL_atmos_cubed_sphere that will update the code to remove the deprecated IO components. Please see FV3 PR #272.

If you don't want to cherry pick those commits, you will need to recompile the FMS library with the -Duse_deprecated_io macro.

[junwang-noaa]

Thanks, Rusty. Since I am running a coupled test with MOM6, I think I will compile fms with -Duse_deprecated_io macro.

[junwang-noaa]

@uramirez8707 I tested your branch in ufs. I think it fixed the starting time issue. In the restart run I have, the starting time 2021032206. the model restarts at fh=03, I want to set average diagnostic field starting time at 2021032212 (skipping accumulating from 2021032209-2021032212) in the ocean history files. I have this in my diag_table:

20210322.06Z.C96.64bit.non-mono
2021 03 22 06 0 0

"ocn%4yr%2mo%2dy%2hr",      6,  "hours", 1, "hours", "time", 6, "hours", "2021 3 22 12 0 0"
"SST%4yr%2mo%2dy",      1,  "days",  1, "days",  "time", 1, "days",  "2021 3 22 12 0 0"

With your fms branch, I got the following output:

ocn_2021_03_22_15.nc
ocn_2021_03_22_21.nc
ocn_2021_03_23_03.nc
ocn_2021_03_23_09.nc
SST_2021_03_23.nc

Which looks correct to me. When I looked at each file, e.g. ocn_2021_03_22_15.nc, I see:

        double time(time) ;
                time:units = "hours since **2021-03-22 06:00:00**" ;
                time:long_name = "time" ;
                time:axis = "T" ;
                time:calendar_type = "JULIAN" ;
                time:calendar = "julian" ;
                time:bounds = "time_bnds" ;
...
 time = 9 ;

 time_bnds =
  6, 12 ;

For the daily average file SST_2021_03_23.nc, I have time_bnds:

        double time(time) ;
                time:units = "days since 2021-03-22 06:00:00" ;
...
 time = 0.75 ;
...
 time_bnds =
  0.25, 1.25 ;

The results are what I expect. Thanks for making the updates. Are you going to have fms release with the code updates? Thanks

[uramirez8707]

@thomas-robinson @rem1776 Can https://github.com/NOAA-GFDL/FMS/pull/1381/files be included in upcoming beta tag and release?

[junwang-noaa]

@thomas-robinson @rem1776 May I ask if you have a timeline to include the changes in a tag? Thanks a lot!

[junwang-noaa]

@thomas-robinson @rem1776 Is it possible that you can create a beta release for us with this updates? We need this for GFSv17 implementation. The issue becomes a blocker to create correct mom6 output files. Thanks for your help!

[rem1776]

@junwang-noaa Sorry for the delay! We are doing initial beta testing for the next release now, if we end up doing another beta tag we will include these changes.

Otherwise if we do go forward with the release, we can likely merge this in right after and create a new tag to test with.

Either way we should be able to get these changes in a tag in a week or so.

[junwang-noaa]

Thanks a lot! We will plan accordingly.

[thomas-robinson]

@junwang-noaa are you running with default real*4? The 2023.03 release will update FMS to support both real*4 and real*8 which may cause some answer changes when compiling/running the components with r4.

[junwang-noaa]

Thanks for letting me know. In our coupled tests, we are running with real4 in fv3 dycore and real8 in MOM6. If you have a beta testing branch, I can test it in UFS.

[thomas-robinson]

@junwang-noaa we are going to patch FMS 2023.02 and create FMS 2023.02.01 for the least impact to your work. @uramirez8707 and @rem1776 are working on it now, so hopefully it will be ready today or Monday. This should not impact your real4 fv3 runs like moving to 2023.03 might.

[junwang-noaa]

That is great! Thank you very much!

[rem1776]

The patch has been released, to use it you would just pull the tag 2023.02.01. Let us know if you have any issues!

[junwang-noaa]

Thank you! We are going to install and test it, will let you know if there is any issues.