CDEPS time logic is flawed for GEFS forcing files

[pjpegion]

I see that the time coming out of the model is not consistent with the time-stamp in the netcdf files for the GEFS forcing files.

If you look at the log files from the regression tests, the cfsr forcing test works correctly:

(shr_strdata_readstrm) reading file lb: DATM_INPUT/cfsr.201110.nc 1
(shr_strdata_readstrm) reading file ub: DATM_INPUT/cfsr.201110.nc 2

but the GEFS forcing shows:

(shr_strdata_readstrm) reading file lb: DATM_INPUT/gefs.201110.nc 21
(shr_strdata_readstrm) reading file ub: DATM_INPUT/gefs.201110.nc 1

I believe this is because of a possible calendar bug, the GEFS files have a time unit of:
time:units = "hours since 1-1-1 00:00:00" ;
time:calendar = "gregorian" ;

I put in a bunch of print statements, and the figuring out out of times is not returning the correct dates.
please see on hera: /scratch2/BMC/gsienkf/Philip.Pegion/stmp2/Philip.Pegion/FV3_RT/rt_86678/datm_cdeps_control_gefs/out.5

[binli2337]

@pjpegion The time units need to be revised for both cfsr and gefs data. The issues were reported in #6.

[binli2337]

@hyunchul386 I think the time units should be changed to "seconds since 1970-01-01 00:00:00.0". Also, the time values need to be recalculated for the GEFS dataset.

[hyunchul386]

@bin Li - NOAA Affiliate ***@***.***> In GFS_DATM, the time unit has been changed to "seconds since 1970-01-01 00:00:00.0". In GEFS, I will change the time unit also.

…

On Wed, Oct 27, 2021 at 5:28 PM BinLi-NOAA ***@***.***> wrote: @hyunchul386 <https://github.com/hyunchul386> I think the time units should be changed to "seconds since 1970-01-01 00:00:00.0". Also, the time values need to be recalculated for the GEFS dataset. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ73E645APENBOIVGGGFQTUJBVF3ANCNFSM5GY57ADQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[binli2337]

@hyunchul386 Thanks!

[binli2337]

@hyunchul386 I have regenerated the GEFS input data used in the current ufs-weather-model regression tests (from 2011100100 to 2011100600).

[hyunchul386]

@binli The GEFS_DATM has been updated for the time stamp issue, and the updated GEFS_DATM can be found at HPSS, /5year/NCEPDEV/marineda/DATM_INPUT/GEFS_new/ Let me know if there are any issues for the data

…

On Fri, Mar 4, 2022 at 4:22 PM BinLi-NOAA ***@***.***> wrote: @hyunchul386 <https://github.com/hyunchul386> I have regenerated the GEFS input data used in the current ufs-weather-model regression tests (from 2011100100 to 2011100600). — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ73EZ67NTNZXUULEN7NELU6J5KNANCNFSM5GY57ADQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[binli]

binli2337

binli2337 is the right person.

[binli2337]

The issue is fixed.