Julian Date Calculation Imprecision Leads to Issues with Time Indices Slicing in the sflux_air_1.0001.nc File about schism

[josephzhang8]

Thx @jduckerOWP.

This is an old issue we discussed 20 yr ago when the atmos scientist was coding sflux*.F90.. The origin of Julian date is indeed at noon (12:00) so the fraction date is not really the true Julian day (offset by 12 hrs). Instead, he decided that the hours in the base_date should be ignored/not read in (this is documented in manual and also in sflux*.F90 code). I know this is confusing. Therefore, the hour in base_date is always 0 even if user specifies otherwise. That's why you got right response when you specify 0 hour in nc file. Hope this explains.

[josephzhang8]

The code ignores hour in base_date so I'll try to remove this in the sample files we generate to avoid confusion.

[jduckerOWP]

@josephzhang8 Thank you very much for the prompt response and background on this issue. SCHISM modelers on our end at the NOAA Office of Water Prediction weren't fully aware I believe of the particular way sflux_air.nc files must be produced so this is good to know on our end now moving forward to get around the confusion of the Julian date offset one visually sees in the mirror.out output. I've confirmed that SCHISM operational product held by NCO has properly accounted for this sflux_air.nc production (days since base date is always at hour 0 when they produce the files for every operational cycle) and doesn't present any issues at this time. I guess this issue raised here is just possibly a fix in the future we could make to avoid confusion with Julian date offsets. Appreciate the explanation and support as always Joseph!