Split run into phys_run1 and phys_run2

[peverwhee]

Summary

This PR brings in the necessary changes (and the necessary framework tag) to split up the physics run into phys_run1 (which calls the "physics_before_coupler" group) and phys_run2 (which calls the "physics_after_coupler" group).

Modifications

phys_comp.F90:

• Create new timestep_final and timestep_init routines
• Call cap run routine for "physics_before_coupler" in phys_run1
• Call cap routine for "physics_after_coupler" in phys_run2
• Verify that the user supplied valid group(s) [only physics_before_coupler and/or physic_after_coupler]

cam_comp.F90:

• Add timestep_init and timestep_final routines so we can call those separately in atm_comp_nuopc
• "use" the physics timestep variable from physics_types (the registry) instead of having it as a module variable here

atm_comp_nuopc.F90:

• Call the new cam_timestep_init before cam_run1
• Call the new cam_timestep_final before timestep advances

phys_comp.meta

• File removed: metadata for horizontal_loop_begin and _end moved to physics_grid.F90; metadata for ccpp_error_message, ccpp_error_code, and timestep_for_physics moved to registry

write_init_files.py:

• Add ccpp_error_message and ccpp_error_code to list of variables we never wish to read from a file

registry_v1_0.xsd

• Update regex to enable "len=xxx" syntax

Testing

Confirmed no answer changes (via ncdata_check) for kessler or held suarez.

[nusbaume]

Thanks for adding this functionality @peverwhee ! However I do wonder if now is a good time to cleanup some of the subroutines in phys_comp.F90, given that we seem to not really need many of the arguments being passed around anymore.

[nusbaume]

Super-close! Just curious why you kept dtime_phys in the calling list for the various subroutines in phys_comp.F90? It doesn't appear to actually be used in many of them.

[nusbaume]

Thanks for tackling the extra clean-up! Everything looks good to me now.

[cacraigucar]

I did find this about groups in the https://github.com/NCAR/ccpp-scm. In the file scm/doc/TechGuide/chap_ccpp.tex, there is a section (note this is .tex, so there are some special characters):

The concept of grouping physics in the suite definition file (currently reflected in the \execout{<group name=XYZ''>} elements) enables groups'' of parameterizations to be called with other computation (perhaps related to the dycore, I/O, etc.) in between. In the suite definition file included in this release, three groups are specified, but currently no computation happens between \execout{ccpp_physics_run} calls for these groups. However, one can edit the groups to suit the needs of the host application. For example, if a subset of physics schemes needs to be more tightly connected with the dynamics and called more frequently, one could create a group consisting of that subset and place a \execout{ccpp_physics_run} call in the appropriate place in the host application. The remainder of the parameterizations groups could be called using \execout{ccpp_physics_run} calls in a different part of the host application code.

This reassured me that what we are doing in this PR is what we should be doing.

[cacraigucar]

Basic question: Should the timestep_init and timestep_final be controlled at the group level as well? I could see that a scheme that is in the "after_coupling" section might need something from the coupling that just happened in the dycore. Also, a "before_coupling" scheme might need to do a timestep_final that prepares something for the dycore.

@nusbaume @peverwhee

[peverwhee]

@cacraigucar I've thought about this as well but couldn't think of a reason why whatever needs to be done before the dycore (or after) couldn't be done as part of the run phase of that scheme. If we added some sort of group-specific version of timestep_final and init, we'd also need to rethink the naming.