GFS physics radiation: solar hour incorrect if model initialized not on the hour

[brianhenn]

The GFS physics radiation routine sets the solar hour (Model%solhr) used to determine cosine of the solar zenith angle and thus radiative fluxes. The way in which it is computed will result in the solar hour being rounded backwards by a fraction of an hour if the model's initialization time is not on the hour (i.e, minutes and seconds are 0 in the initial date). This is because solar hour is computed as the sum of the fractional hour since initialization plus the integer hour of initialization. There is not any problem if the model is initialized on the hour, but if initialized off the hour, the physics will use a solar hour that is shifted by the sub-hourly amount. Thus any forecasts outputs and diagnostics involving time and solar diurnal cycle will be nominally incorrect (the internal dynamics and physics of the model presumably aren't affected).

To Reproduce
Initialize SHiELD with a not-on-the-hour initialization time; the peak downward shortwave flux will not be at 0° longitude at 12Z, for example (neglecting eq. of time), but will instead be shifted east by 0.0 < subhour < 1.0 hours (0.0 < deg < 15.0), where subhour is the fraction of the hour after the last full hour in the initialization time.

Expected behavior
The solar hour result should not be shifted in this way. Instead, the solar hour should be computed from the fractional hours elapsed since initialization plus the fractional hour of initialization (instead of the integer hour of initialization).

[lharris4]

Hi, Brian. Thanks for finding this. I know that the model needs to be restarted on the radiation timestep to ensure reproducibility since the radiation is only called at those times. Do you have a solution in mind? Lucas

…

On Mon, Oct 24, 2022 at 3:44 PM Brian Henn ***@***.***> wrote: The GFS physics radiation routine sets the solar hour (Model%solhr) used to determine cosine of the solar zenith angle and thus radiative fluxes. The way in which it is computed <https://github.com/NOAA-GFDL/SHiELD_physics/blob/2882fdeb429abc2349a8e881803ac67b154532c3/GFS_layer/GFS_driver.F90#L331> will result in the solar hour being rounded backwards by a fraction of an hour *if* the model's initialization time is not on the hour (i.e, minutes and seconds are 0 in the initial date). This is because solar hour is computed as the sum of the fractional hour since initialization plus the *integer* hour of initialization. There is not problem if the model is initialized on the hour, but if initialized off the hour, the physics will use a solar hour that is shifted by the sub-hourly amount. Thus any forecasts outputs and diagnostics involving time and solar diurnal cycle will be nominally incorrect (the internal dynamics and physics of the model presumably aren't affected). *To Reproduce* Initialize SHiELD with a not-on-the-hour initialization time; the peak downward shortwave flux will not be at 0 deg longitude at 12Z, for example, but will instead be shifted east by 0.0 < subhour < 1.0 hours, (0.0 < deg 15.0) where subhour is the fraction of the hour after the last full hour in the initialization time. *Expected behavior* The solar hour result should not be rounded in this way. Instead, the solar hour should be computed from the fractional hours elapsed since initialization plus *the fractional hour of initialization* (instead of the integer hour of initialization). — Reply to this email directly, view it on GitHub <#17>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVBTJXTS4V2YV6U4TTLWE3RKVANCNFSM6AAAAAARNJMWUY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[brianhenn]

Hi Lucas, thanks for checking in here.

I think the issue I pointed out is independent of whether to restart on the radiation timestep? My proposed solution is to compute the solar hour based on the sum of the fractional hours elapsed since the initialization time and the fractional hour of initialization (instead of the integer hour), modulo 24 hours. Since the fractional hours elapsed is computed from the fractional initial hour, this ensures that the correct solar hour is used, instead of one that is off by a sub-hourly amount.

[lharris4]

Hi, Brian. Sorry for losing track of this. I do believe that this would be the correct solution. Please feel free to open a MR with a proposed fix. Thanks Lucas

…

On Fri, Nov 4, 2022 at 7:19 PM Brian Henn ***@***.***> wrote: Hi Lucas, thanks for checking in here. I think the issue I pointed out is independent of whether to restart on the radiation timestep? My proposed solution is to compute the solar hour based on the sum of the fractional hours elapsed since the initialization time and the *fractional* hour of initialization (instead of the integer hour), modulo 24 hours. Since the fractional hours elapsed is computed from the fractional initial hour, this ensures that the correct solar hour is used, instead of one that is off by a sub-hourly amount. — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVF3EVV3V5B4X3YAL6TWGWKXVANCNFSM6AAAAAARNJMWUY> . You are receiving this because you commented.Message ID: ***@***.***>