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
Following the merge of #534 (implementation of the timestep_init and timestep_final CCPP phases), it may be beneficial to reorganize existing GFS-based "time_vary" schemes. GFS_time_vary_pre contains code that 1) should get executed every physics timestep before anything else and 2) is purely dependent on time (nothing domain-dependent or with horizontal extent). GFS_rad_time_vary and GFS_phys_time_vary do stuff that 1) needs to be executed at the beginning of every timestep and 2) is dependent on time AND has horizontal extent. Historically, the former code came from above the "gbphys/grrad" software layer of the GSM-based GFS and the latter came from the gbphys/grrad software layers. That is, the differentiation between the current GFS-based "time_vary" interstitial schemes may not be important anymore, given the maturation of the CCPP-framework and the timestep_init phase in particular.
One simplification would be to keep the order of operations the same (time_vary, rad_time_vary, phys_time_vary), but put them in one scheme/timestep_init phase. This would slightly simplify existing GFS-based SDFs and provide one place to put GFS suite-generic timestep_init code.
The text was updated successfully, but these errors were encountered:
Following the merge of #534 (implementation of the timestep_init and timestep_final CCPP phases), it may be beneficial to reorganize existing GFS-based "time_vary" schemes. GFS_time_vary_pre contains code that 1) should get executed every physics timestep before anything else and 2) is purely dependent on time (nothing domain-dependent or with horizontal extent). GFS_rad_time_vary and GFS_phys_time_vary do stuff that 1) needs to be executed at the beginning of every timestep and 2) is dependent on time AND has horizontal extent. Historically, the former code came from above the "gbphys/grrad" software layer of the GSM-based GFS and the latter came from the gbphys/grrad software layers. That is, the differentiation between the current GFS-based "time_vary" interstitial schemes may not be important anymore, given the maturation of the CCPP-framework and the timestep_init phase in particular.
One simplification would be to keep the order of operations the same (time_vary, rad_time_vary, phys_time_vary), but put them in one scheme/timestep_init phase. This would slightly simplify existing GFS-based SDFs and provide one place to put GFS suite-generic timestep_init code.
The text was updated successfully, but these errors were encountered: