You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are applying the diurnal cycle of precipitation POD to the FV3 model output and have identified two errors (listed below) in this POD associated with the timing of the 3-hour intervals, which varies in the different input dataset. For instance, the 3-hour intervals are on 00, 03, 06, ..., 21 for the observation (TRMM dataset) while the models we test are on 01, 04, 07, ..., 22. I am not sure if other models following the CF-standard still have this problem. But the diagnostic results will suffer from the following problems:
In the script named pr_diurnal_cycle.ncl, there is a variable called cam_time_shift=-0.5 (L33), which is designed to plus a 30-min to shift the phase of the time-axis for the time step in the CAM model (L363). However, we think this value should be dependent on the input model.
Another issue in the same script is caused by the linear interpolation of the 3-hour interval into the one-hour interval. This problem is linked to the t_shift_dc variable (L363&L375), which converts the UTC to the local time (LT). However, the different range of longitude, 0~360 (e.g., most of the model input) versus -180-180 (e.g., TRMM dataset), would result in a one-hour difference in the calculated diurnal phase. The problem is rooted in the fact that the length of the array created to hold the interpolated 24-hour dataset is set to 25 (the first and the last are the same).
The text was updated successfully, but these errors were encountered:
We are applying the diurnal cycle of precipitation POD to the FV3 model output and have identified two errors (listed below) in this POD associated with the timing of the 3-hour intervals, which varies in the different input dataset. For instance, the 3-hour intervals are on 00, 03, 06, ..., 21 for the observation (TRMM dataset) while the models we test are on 01, 04, 07, ..., 22. I am not sure if other models following the CF-standard still have this problem. But the diagnostic results will suffer from the following problems:
In the script named pr_diurnal_cycle.ncl, there is a variable called cam_time_shift=-0.5 (L33), which is designed to plus a 30-min to shift the phase of the time-axis for the time step in the CAM model (L363). However, we think this value should be dependent on the input model.
Another issue in the same script is caused by the linear interpolation of the 3-hour interval into the one-hour interval. This problem is linked to the t_shift_dc variable (L363&L375), which converts the UTC to the local time (LT). However, the different range of longitude, 0~360 (e.g., most of the model input) versus -180-180 (e.g., TRMM dataset), would result in a one-hour difference in the calculated diurnal phase. The problem is rooted in the fact that the length of the array created to hold the interpolated 24-hour dataset is set to 25 (the first and the last are the same).
The text was updated successfully, but these errors were encountered: