In addition to "init," "timestep_init", "run," "timestep_final," and "final", there will be a "register" phase that will be called by the host prior to grid set-up.
Solution
The register phase will be implemented as any other phase, with the bonus of also handling any run-time constituents for a scheme (this will replace the existing dyn_const_routine field in the metadata header).
@peverwhee This is a great idea and there is a need for such a phase for NOAA applications.
A few examples come to mind where this would be useful.
For physics suites that have groups called outside of the physics loop (i.e. from the dynamical core), we need to be able to initialize this group on the host side before both the physics and dynamical core. @yangfanglin @RuiyuSun
There are some physics schemes that require dynamic allocation of interstitials (e.g NRL photochemistry, RRTMGP, MG-MP). These schemes all have a run-time data component that needs to be known so that the interstitials can be allocated properly.
Description
In addition to "init," "timestep_init", "run," "timestep_final," and "final", there will be a "register" phase that will be called by the host prior to grid set-up.
Solution
The register phase will be implemented as any other phase, with the bonus of also handling any run-time constituents for a scheme (this will replace the existing dyn_const_routine field in the metadata header).