search

schism-dev / schism

Semi-implicit Cross-scale Hydroscience Integrated System Model (SCHISM)
http://ccrm.vims.edu/schismweb/
Apache License 2.0
78 stars 84 forks source link

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

Closed jduckerOWP closed 3 weeks ago

jduckerOWP commented 3 weeks ago

@josephzhang8 the explanation before highlights the SCHISM workflow leading to issues from SCHISM Julian Date calculations and its reference to the time slicing method for the sflux_air_1.0001.nc file based on the user start time within the param.nml file.

The Julian Date for SCHISM is derived based on the user start time specifications (start year, start month, start day, start hour) within the param.nml file. Most users are setting up their models based on UTC time, so the user will generally keep the "utc_start" variable at 0.0 as well in this case. Inherently, the Julian Date calculation (subroutine JD()) within the src/Hydro/sflux.F90 file has floating precision errors for the true Julian Date estimate of the SCHISM start time.

Example: start_year = 2024, start_month = 5, start_day = 30.0, start_hour = 12.0, utc_start = 0.0 SCHISM "start_frac_jdate" = 2460461.5 True Julian fractional date = 2460461.0

This directly impacts the time slice estimate of the sflux_air_1.0001.nc file in general with the Julian date estimates of the "start" and "end" time of the time indices within that atmospheric forcing file. What is interesting however is the Julian date offset will still properly slice the time indices of the sflux_air_1.0001.nc file ONLY if the user calculates the time variable (days since "base_date") in the sflux_air_1.001.nc file using a "base_date" of the same day at UTC hour 0 (example above would need a base_date = 2024-05-30 00:00:00). If the user however in this case were to calculate the time variable within the "sflux_air_1.001.nc" file using a base_date that is equivalent to its own start time (2024-05-30 12:00:00), then SCHISM will offset the time slice of "sflux_air_1.001.nc" by 12 hours automatically at very start of the simulation. This would lead to SCHISM throwing an error within the "get_sflux_data" subroutine related to "no appropriate time exists for time_now" 12 hours before the end of the actual simulation due to the Julian Fractional Date imprecision that SCHISM inherently derived.

My general recommendation here would be to revise the subroutine "JD" to fix accuracy issues with calculating the Julian Day integer as well as the calculation for the variable "start_frac_jdate" here. I have some suggestions here for this fix, but I want to at least start these discussions and inquire whether or not you've had previous users highlighting such an issue like this before?

josephzhang8 commented 3 weeks ago

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 commented 3 weeks ago

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

jduckerOWP commented 3 weeks ago

@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!