rain variable refactoring

[grantfirl]

Code checked B4B on cheyenne (using Dom's ESMF).

I created 4 new local variables in GFS_physics_driver which will need to go into IPD_Data(nb)%Interstitial:

New "interstitial" variables
!! lwe_thickness_of_deep_convective_precipitation_amount | deep convective rainfall amount on physics timestep | m | 1 | real | kind_phys | out | F |
!! lwe_thickness_of_shallow_convective_precipitation_amount | shallow convective rainfall amount on physics timestep | m | 1 | real | kind_phys | in | F |
!! lwe_thickness_of_moist_convectie_adj_precipitation_amount | moist convective adjustment rainfall amount on physics timestep | m | 1 | real | kind_phys| out | F |
!! lwe_thickness_of_stratiform_precipitation_amount | stratiform rainfall amount on physics timestep | m | 1 | real | kind_phys| out | F |

All of these use "lwe_thickness_of_X_precipitation_amount" per CF standards. All are in units of meters. The one used in the moist convective adjustment scheme is technically not needed for operational GFS physics, but it was the last remaining use of "rain1" in GFS_physics_driver.F90, so I changed it for completeness.

The remaining variables that were changed were preexisting variables within the GFS DDTs:
Diag%rainc => lwe_thickness_of_convective_precipitation_amount_on_dynamics_timestep | convective rainfall amount on dynamics timestep | m | 1 | real | kind_phys | in | F |
Diag%rain => lwe_thickness_of_precipitation_amount_on_dynamics_timestep | total rainfall amount on dynamics timestep | m | 1 | real | kind_phys | out | F |
Diag%cnvprcp => accumulated_lwe_thickness_of_convective_precipitation_amount | convective rainfall amount accumulated for diagnostics | m | 1 | real | kind_phys
Diag%totprcp => accumulated_lwe_thickness_of_precipitation_amount | total rainfall amount accumulated for diagnostics | m | 1 | real | kind_phys
Sfcprop%tprcp => nonnegative_lwe_thickness_of_precipitation_amount_on_dynamics_timestep | total rainfall amount on dynamics timestep used in surface schemes | m | 1 | real | kind_phys
Tbd%acv => accumulated_lwe_thickness_of_convective_precipitation_amount_cnvc90 | convective rainfall amount accumulated for cnvc90 | m | 1 | real | kind_phys
Tbd%dcnvprcp => dynamics_timestep_change_in_lwe_thickness_of_convective_precipitation_amount | change in convective rainfall amount during one timestep | m | 1 | real | kind_phys
Tbd%dtotprcp => dyanamics_timestep_change_in_lwe_thickness_of_precipitation_amount | change in total rainfall amount during one timestep | m | 1 | real | kind_phys

Again, Tbd%dcnvprcp and Tbd%dtotprcp are not used in operational physics (are used in stochastic physics), but their names were changed for completeness. All variables are in meters and therefore use the "lwe_thickness" language. Diag%rain and Diag%rainc are valid for the current timestep (and have been multiplied by the dtf/dtp factor - so assumed to be valid for the dynamics timestep). Sfcprop%tprcp is the same as Diag%rain except there is a stanza to ensure that it is >= 0. This variable is used for surface schemes during the next call to physics. Diag%cnvprcp and Diag%totprcp are accumulated for diagnostics and periodically zeroed out. Tbd%acv is an odd duck -- it has accumulated convective precipitation, but it is zeroed out on a different frequency within cnvc90.

Within the physics code, it appears that ALL of the variables are in meters. Within the registry, some of these get converted into kg m-2 by applying a conversion factor within FV3GFS_io.F90 (1.0E3 = density of water) and some of them further get converted into rates by dividing by time in GFS_diagnostics.F90. Therefore, there appears to be a discrepancy in the comments within GFS_typedefs.f90 (cnvprcp and totprcp within GFS_diag_type) that says the units are kg/m2. The conversion happens outside of physics.

[climbfuji]

Impressive, thanks grant for getting this done so quickly. I have no objections, approved.