Implementation of CCPP timestep_init and timestep_final phases

[climbfuji]

This PR contains the following changes:

• Implementation of CCPP timestep_init and timestep_final phases in model/fv_dynamics.F90

Note that while these new phases are currently not doing any work, they are required for transitioning to the new CCPP code generator capgen.py (scheduled for February 2021), at which time they will be taking over some of the work that is currently done manually (allocating data for the CCPP fast physics calls).

Associated PRs:

ufs-community/ufs-weather-model#337
NOAA-EMC/fv3atm#217
NCAR/ccpp-physics#534
NCAR/ccpp-framework#344
#47

For regression testing information, see ufs-community/ufs-weather-model#337.

[climbfuji]

I am opening this PR for review. I will have to pull in updates from NOAA-EMC dev/emc in case anything gets committed until it is the turn for this PR (I am only aware of the "remove mpp_node" PR). But the code changes itself should be final.

[climbfuji]

@junwang-noaa @DusanJovic-NOAA please add reviewers, thanks!

[XiaqiongZhou-NOAA]

I do not understand CCPP completely, but still feel the changes are OK.

[bensonr]

My understanding is the timestep init and finalize replace the physics time-varying pre-step global operations. It also appears these same functions now have stages called out by the particular group_name. I assume these functions are being added here for consistency and not because the fast_physics group is actually performing any pre-physics global operations - is that correct?

To futureproof for when others add more physical parameterizations at the "fast_physics" timescale but with no dynamical core dependencies, is this the proper place to be calling the timestep init and finalize?

[climbfuji]

My understanding is the timestep init and finalize replace the physics time-varying pre-step global operations. It also appears these same functions now have stages called out by the particular group_name. I assume these functions are being added here for consistency and not because the fast_physics group is actually performing any pre-physics global operations - is that correct?

Yes, that is correct.

To futureproof for when others add more physical parameterizations at the "fast_physics" timescale but with no dynamical core dependencies, is this the proper place to be calling the timestep init and finalize?

We (DTC CCPP developers) don't really have any knowledge of how/where exactly additional fast physics processes will be added. It seems likely, though, that they will be inside the actual call to the dynamics (fv_dynamics), in which case calling timestep_init and timestep_final at the beginning and end of the routine makes sense to me.

But please correct me if my understanding is incorrect and you think there are more suitable places for these calls.

[bensonr]

@climbfuji - I don't think there is a more suitable place at this point in time. I'll give it another look-see and post a new review.