Consistency between radiation and P3 microphysics

[AaronDonahue]

Per discussion with @brhillman, it is possible that the radiation interface that handles pbuf variables provided by microphysics has assumptions that are tied to running MG microphysics. In particular, microphysics provides the shape and slope parameters mu_c and lambda_c which correspond to a size distribution for liquid cloud drops.

It's possible that the size distribution assumed by the radiation scheme is based on MG, and may not be the same distribution in P3.

I'm opening this issue to start a discussion and so that there is a record of our thoughts on this matter.

[PeterCaldwell]

Yes, I'm pretty sure the rad interface assumes MG2 radiation is used. I've been trying to find time to look at the rad code, but I'm not sure when I will be able to...

[AaronDonahue]

In terms of moving forward I was going to look into whether or not we got lucky and P3 assumes the same distribution as MG for liquid cloud droplets. In the long term this seems like something that needs to be addressed, but in the short term we may be able to proceed with PR #95 .

Anecdotally, in the papers for both MG and P3 they reference the same paper when discussing the liquid cloud distribution.

[PeterCaldwell]

Yeah, it would be great if you could check the distributions used in rad... I bet you could get a long way before I jump in.

[brhillman]

There isn't much to go off of in the cloud optics code that I can find. Some lookup tables are read from netcdf files, and the MG variables "LAMBDAC" and "MU" are used to retriev appropriate values. For the SW liquid optics, this file has the name "F_nwvl200_mu20_lam50_res64_t298_c080428", which does not mean much to me, and there does not seem to be any documentation in the code, and no global attributes on the netcdf file to suggest where the values are coming from or what distribution is assumed. The extent of the documentation is that we are using the "Mitchell" SW and LW ice properties, and the "Conley" SW and LW liquid properties. Hoping digging into the microphysics is more fruitful.

[AaronDonahue]

I did some investigating on how lambda_c and mu_c are calculated in P3 and MG microphysics. They match with only one small difference. In P3, mu_c is capped at a maximum of 15., while in MG that isn't the default behavior. Without getting too much in the weeds, if the CLUBB_BFB compiler flag is turned on then it will cap mu_c at a max of 15., otherwise mu_c is allowed to be as big as we want.

side note, in both MG and P3 mu_c is lower bound by 2.

[AaronDonahue]

I'll add that the rel properties are also the same in both MG and P3.

[PeterCaldwell]

Thanks Aaron. So if we didn't cap mu_c at 15 in p3, we would be using the same behavior as P3? That's good fortune. So far it seems like we've focused on liquid properties rather than ice properties. is there also a lambda_i and mu_i (or other variables we haven't checked yet) being used by rad?

Also, it's a bummer that this stuff is handled via table lookup. It's becoming clear that a major problem with table lookups is that all provenance and sense of what the table is doing quickly disappears.

[pressel]

@AaronDonahue this is indeed fortuitous. @PeterCaldwell I share you concerns about the lookup tables, how hard would it be to have the lookup tables generated at compile time or as part of the model initialization process? In previous codes I have worked on, lookup tables were generated at initialization to avoid provenance/conceptual issues.

[AaronDonahue]

@PeterCaldwell , to answer your question on ice, here we bump up against the opaque lookup tables in P3. The only variable that I can see which is passed from microphysics to RAD based on ice properties is DEI (the effective diameter of ice) and is calculated based on REI (the effective radius of ice). Here is the chunk of code handling this in MG:

           effi(i,k) = 1.5_r8/lami(i,k)*1.e6_r8
...
           ! ice effective diameter for david mitchell's optics
           deffi(i,k)=effi(i,k)*rhoi/rhows*2._r8

here deffi is DEI and effi is REI in the E3SM variable names. In P3 we calculate DEI using the same formula based on REI, but in PR #95 I switched rhoi from a constant of 500 (as it is in MG) to the P3 equivalent, which turns out to be from the lookup tables for ice. For REI in P3, this is directly taken from the lookup table, see diag_effi(i,k) = f1pr06 ! units are in m from the P3 code. So it isn't clear from the code if they are similar or not.

I would also add that MG doesn't appear to have an equivalent mu_i term for ice, instead it calculates lambda_i (lami in the code) using the equivalent of mu_i=1 always. Not sure if this is important, but probably worth mentioning.

@pressel , in response to your comment. Currently this is what is done for the rain lookup table, it is constructed during the initialization step. I wonder if ice is just prohibitively expensive to construct? I would agree though that the opaqueness of the lookup tables is both troubling and difficult. For example with REI above, the value is taken from the lookup table and I basically have no way of checking to see if it is in any way similar to what MG is doing.

[AaronDonahue]

@brhillman , correct me if I'm wrong but MU, LAMBDAC and DEI are the only PBUF variables that RAD actually uses. I know that REI and REL are added to PBUF, but if I recall from our previous conversations they aren't actually used in RAD. Am I missing any other variables passed from micro to rad?

I guess there is DES, but we don't have snow so we will have to deal with this separately.

[brhillman]

Also ICLWP and ICIWP. REL and REI were only used by a previous cloud optics scheme.

[AaronDonahue]

Ok great, thanks. Looking at ICLWP and ICIWP, it appears those are calculated in cloud_diagnostics.F90, and not directly in the microphysics scheme. This is dependent on the state, but the conv_water_4rad call does depend on REI and FICE. So in a roundabout way REI is still important for RAD calculations. I'm going to verify that we are handling FICE correctly.

Correction: FICE is handled by CLUBB/SHOC not microphysics.

[bartgol]

Is this still a concern? @AaronDonahue @brhillman , please close if it's not.