Allow microphysics schemes to pass effective radius values to radiation

[AndersJensen-NOAA]

An option should be added to save cloud, ice, and snow effective radius values from the microphysics and send those values directly to the radiation.

[dustinswales]

This is already a feature.

For RRTMG, clw, which contains the gridmean cloud properties, q and Re for active species, is passed into the "cloud-to-radiation interface", radiation_clouds.f.
From here cloud radiative properties are computed and passed to the radiation.

For RRTMGP we went a step further and allowed for multiple cloud types (gridmean, convective and PBL) to be passed into the radiation in the "cloud-to-radiation interface" GFS_rrtmgp_cloud_mp.F90

In any case, if you want to add more cloud information for the radiation "to see", you need to add it to one of the "cloud-to-radiation" interfaces, not the radiation directly.
Both radiation schemes use cloud radiative properties (e.g., Re, optical paths) computed by these interfaces.

[AndersJensen-NOAA]

Thanks @dustinswales for the reply. My understanding of how Thompson works (and subsequently TEMPO) is that the effective radius values for cloud, ice, and snow are calculated in GFS_RRTMG_pre (the microphysical procedures are imported into RRTMG_pre).

Are you saying that these effective radius values can be calculated directly in the microphysics (actually computed in mp_tempo) and then passed through to radiation? That is what I would like to do for Tempo.

[dustinswales]

Thanks @dustinswales for the reply. My understanding of how Thompson works (and subsequently TEMPO) is that the effective radius values for cloud, ice, and snow are calculated in GFS_RRTMG_pre (the microphysical procedures are imported into RRTMG_pre).

This is correct.
For GP this is in GFS_rrtmgp_cloud_mp.pre (The idea was that MP developers would only need to touch this one file, but we are still using RRTMG which has things in ten places)

Are you saying that these effective radius values can be calculated directly in the microphysics (actually computed in mp_tempo) and then passed through to radiation? That is what I would like to do for Tempo.

This all comes down to the differences in the P2D coupling between the FV3 and MPAS dynamical cores.

In MPAS, the call sequence is as follows: Physics (all but MP) -> MPAS dycore -> Physics (MP) -> .....
In FV3, the call sequence is as follows: Physics (all) -> FV3 dycore -> ....

At subsequent time-steps in MPAS you use the effective radii directly from the MP, whereas in FV3 they need to be recalculated using the updated (advected) state. This is why we call calc_effectRad from GFS_rrtmg_pre(GFS_rrtmgp_cloud_mp).

@grantfirl We will need to handle this with the P2D for UFS-MPAS. I think we just need to modify the cloud-to-radiation interfaces, GFS_rrtmg_pre or GFS_rrtmgp_cloud_mp, with some simple logic to either recompute particle-sizes (if FV3) or pass through particle-sizes (if MPAS).

[dustinswales]

@AndersJensen-NOAA Can you proceed with your TEMPO implementation in a FV3 way? (i.e. recomputing Re at the start of the physics loop)
Then either @grantfirl or myself can update the cloud-to-radiation interfaces needed for the MPAS transition.
I created a new tag "Unified P2D coupling" to keep track of these kind of things. There's a good chance that there will be more instances :)

[AndersJensen-NOAA]

@dustinswales Done! things should work now (I've havent rerun the tests yet though).

[dustinswales]

@AndersJensen-NOAA Thank you!