Minor cloud tunings to improve cloud fraction and radiation in UFS

[gthompsnWRF]

This PR is attempting to increase some cloud ice aloft explicitly in the Thompson microphysics by permitting a larger number of ice crystals (as a maximum) and by overall decreasing the fractional cloudiness in the Thompson cloud fraction scheme (subroutine cal_cldfra3). The following list of 4 items describes the changes introduced by this PR:

1. permit maximum of 5000 ice crystals per Liter (previously 500).
2. return to using 10% of snow mass assumed as cloud ice in radiation scheme.
3. alter the equation for cloud fraction to use SQRT(SQRT(expression)) in place of a single square root (see graphic below for how that affects the outcome).
4. for readability purposes, I added a blank line around some subroutines and removed authors initials hnhj because this author was already credited in a comment block and having initials on many lines is pointless.

The first two items listed above are intended to improve explicitly-created clouds by the microphysics whether or not the icloud = 3 option is attempted. The third item is an attempt to reduce what was seen as too much high-altitude ice cloud causing outgoing longwave radiation to be too low compared to the 240 W/m2 target value.

The graphic below represents the cloud fraction diagnosed as a function of relative humidity for a sample condition of approximately 13km horizontal grid spacing and 250m vertical level spacing to arrive at the Critical RH values of 0.82 over land (red) and 0.90 over ocean (blue). Dashed lines are the older diagnosis and solid lines with dots are the outcome of the new code.

[gthompsnWRF]

@gthompsnWRF These changes look fine to me. Do you know if these changes are desired/required for any releases in order to inform the merge process?

I am not yet sure. Perhaps if someone at EMC could answer that question. Also, I am making a couple more really small changes meant for collaborations with NOAA-GSL who is wishing to see slightly lower reflectivities in RRFS. So I have test case I am running at the moment to address their concern as well. Should be some useful changes by end of this week and they will be quite small tunings.

[yangfanglin]

@grantfirl @gthompsnWRF If Greg is referring to the changes made to icould=3 scheme, we are not using this scheme for UFS prototypes (yet). The other changes Greg made inside Thompson MP had been tested showed slight positive impact on the UFS prototype 8. It would be nice to have them included in the upcoming UFS prototype runs.

@gthompsnWRF Greg, will the "a couple more really small changes meant for collaborations with NOAA-GSL " also address the computation of radar reflectivity for the global model as we discussed in the microphysics meeting ?

[gthompsnWRF]

@yangfanglin Yes, the reflectivity changes are also intended to support global simulations. I have them in my compiled code but haven't pushed those changes to this branch yet because I'm waiting to test in RRFS first.

[grantfirl]

@yangfanglin Yes, the reflectivity changes are also intended to support global simulations. I have them in my compiled code but haven't pushed those changes to this branch yet because I'm waiting to test in RRFS first.

@gthompsnWRF Thanks. Please put a comment on this PR when you're ready to have it re-reviewed and I'll remove the work-in-progress label.

[gthompsnWRF]

@grantfirl Who would I ask that we finally change the name of this file: Thompson_MP_MONTHLY_CLIMO.nc -> QNWFA_QNIFA_SIGMA_MONTHLY.nc

I do not like my name attached directly to this file and don't see how it got there from the name of the WRF file. It's not a microphysics file per se. It's an aerosol file derived from GOCART and Trude Eidhammer did the majority of work on it, not me so I don't like the misplaced name.

[grantfirl]

@grantfirl Who would I ask that we finally change the name of this file: Thompson_MP_MONTHLY_CLIMO.nc -> QNWFA_QNIFA_SIGMA_MONTHLY.nc

I do not like my name attached directly to this file and don't see how it got there from the name of the WRF file. It's not a microphysics file per se. It's an aerosol file derived from GOCART and Trude Eidhammer did the majority of work on it, not me so I don't like the misplaced name.

@gthompsnWRF Good question. Since it is an input file, I'm guessing that one of the UFS code managers that has permission to change input files should do this on supported platforms. I'm also guessing that whichever scripts move input files to run directories will also need to change to reflect the changed filename? @junwang-noaa @BrianCurtis-NOAA @DusanJovic-NOAA @MinsukJi-NOAA

[climbfuji]

@grantfirl Who would I ask that we finally change the name of this file: Thompson_MP_MONTHLY_CLIMO.nc -> QNWFA_QNIFA_SIGMA_MONTHLY.nc I do not like my name attached directly to this file and don't see how it got there from the name of the WRF file. It's not a microphysics file per se. It's an aerosol file derived from GOCART and Trude Eidhammer did the majority of work on it, not me so I don't like the misplaced name.

@gthompsnWRF Good question. Since it is an input file, I'm guessing that one of the UFS code managers that has permission to change input files should do this on supported platforms. I'm also guessing that whichever scripts move input files to run directories will also need to change to reflect the changed filename? @junwang-noaa @BrianCurtis-NOAA @DusanJovic-NOAA @MinsukJi-NOAA

This is more on the global workflow / UFS_UTILS side, because the ufs-weather-model itself doesn't need this file? It gets the aerosols from the initial conditions (UFS_UTILS preprocesses the aerosol climatology and adds it to the initial conditions).

[yangfanglin]

@GeorgeGayno-NOAA @KateFriedman-NOAA George and Kate, could you please check the "FIX" directory, rename Thompson_MP_MONTHLY_CLIMO.nc to QNWFA_QNIFA_SIGMA_MONTHLY.nc, and update all associated scripts ?

[KateFriedman-NOAA]

@GeorgeGayno-NOAA @KateFriedman-NOAA George and Kate, could you please check the "FIX" directory, rename Thompson_MP_MONTHLY_CLIMO.nc to QNWFA_QNIFA_SIGMA_MONTHLY.nc, and update all associated scripts ?

@yangfanglin Please open a global-workflow issue to request the fix file name-change and associated script updates. I'll handle the fix file name-change and myself or another developer will take care of the script updates. Thanks!

[grantfirl]

@gthompsnWRF Is this still a work-in-progress, or is it ready to be added to the commit queue?

[gthompsnWRF]

@gthompsnWRF Is this still a work-in-progress, or is it ready to be added to the commit queue?

Almost finished. Need to check and clear a few things further with GSL folks.

[ligiabernardet]

Label CCPP v6 based on information provided by @yangfanglin that this PR will not be needed for p8c or p8.1. Since CCPP v6 will very closely match one of those p8 configurations, this tuning does not need to be in this release (it can be part of future releases).

[grantfirl]

@gthompsnWRF There is another UFS commit scheduling meeting today. Is this ready to enter the queue now?

[grantfirl]

@gthompsnWRF Hi Greg, we're going through old pull requests again and trying to understand their statuses. Would you like to keep this tuning PR open to potentially merge at some point in the near future, or should we close and reopen if necessary?

[gthompsnWRF]

@gthompsnWRF Hi Greg, we're going through old pull requests again and trying to understand their statuses. Would you like to keep this tuning PR open to potentially merge at some point in the near future, or should we close and reopen if necessary?

I wish to request that we merge in this PR and I can make another minor adjustment involving very few lines of code if I can make the time for some newer tests. I am pretty content with the results produced by this change although a bit more improvement might be possible. The small merge conflict relates to comments. I just don't think we need those ! hmhj attributions as comments since older revisions are always possible to view.

[grantfirl]

@gthompsnWRF Hi Greg, we're going through old pull requests again and trying to understand their statuses. Would you like to keep this tuning PR open to potentially merge at some point in the near future, or should we close and reopen if necessary?

I wish to request that we merge in this PR and I can make another minor adjustment involving very few lines of code if I can make the time for some newer tests. I am pretty content with the results produced by this change although a bit more improvement might be possible. The small merge conflict relates to comments. I just don't think we need those ! hmhj attributions as comments since older revisions are always possible to view.

OK, let's do that. Since this is a bit out-of-date and I need to make upstream PRs anyway, I'm going to go ahead and pull your changes in this PR branch into a fresh one off of main for the purposes of doing UFS RTs and merging. Once the new branch is in place, I'll submit a new PR and give you credit of course. This is just easier rather than forcing you to go through the rigamarole of updating your branch. This should resolve merge conflicts too.

[grantfirl]

I'm closing this PR in favor of https://github.com/ufs-community/ccpp-physics/pull/1 into the ufs/dev branch.