Skip to content

cloud cover change associated with xu_randall#789

Merged
climbfuji merged 7 commits into
NCAR:mainfrom
RuiyuSun:cloud_cover_xr
Dec 20, 2021
Merged

cloud cover change associated with xu_randall#789
climbfuji merged 7 commits into
NCAR:mainfrom
RuiyuSun:cloud_cover_xr

Conversation

@RuiyuSun
Copy link
Copy Markdown
Contributor

@RuiyuSun RuiyuSun commented Dec 1, 2021

Modify the xu/randall cloud cover (progcld6) to have more cloud cover

Fixes #765

Associated PRs:

NOAA-EMC/ufsatm#443
ufs-community/ufs-weather-model#962

@climbfuji
Copy link
Copy Markdown
Collaborator

Forgive me my ignorance, but didn't @AnningCheng-NOAA find that the new Thompson cloud cover scheme in PR #781 produces too much cloud cover? Does this mean that once #781 is merged, this PR won't be needed?

As per our offline discussion, my understanding was wrong - this PR can be merged with or after #781.

@yangfanglin
Copy link
Copy Markdown

yangfanglin commented Dec 2, 2021 via email

@climbfuji
Copy link
Copy Markdown
Collaborator

Dom, We need to make a decision in December whether or not to include Thompson MP in the UFS Prototype 8. After discussing with Greg, Ruiyu and a few other developers we came up with two plans. Plan A for the short term: include in P8 all but the ice_RHc updates Ruiyu had made before, and additional tuning of Xu&Randall to improve cloud cover and radiative fluxes. So far the results are encouraging. Plan B: use Greg's branch and tune the parameters to improve cloud cover and radiative fluxes. This will take some time to complete. Once plan B is ready, it will be used to replace plan A in the prototypes. To conclude, this PR is still needed to meet our short-term goals. Thanks Fanglin

Thanks, Fanglin, this sounds like a good plan. Please let us know if there is something we can do to facilitate the process.

Copy link
Copy Markdown
Collaborator

@grantfirl grantfirl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Straightforward changes. Approved.

@grantfirl
Copy link
Copy Markdown
Collaborator

@climbfuji Are you going to put this and #781 in a wrapper PR?

@climbfuji
Copy link
Copy Markdown
Collaborator

@climbfuji Are you going to put this and #781 in a wrapper PR?

Yes - thanks for the reminder. I will then direct the fv3atm that goes with Greg's changes to the combined PR.

@climbfuji
Copy link
Copy Markdown
Collaborator

This PR was pulled into #795. It will be merged (and automatically closed) when #795 gets merged.

Copy link
Copy Markdown
Contributor

@SamuelTrahanNOAA SamuelTrahanNOAA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good. One warning though: when you type "0.49," you get 0.49 in default real kind, not kind_phys. You might be doing calculations at a lower precision than you intended. The rest of the file has the same issue, so I see no reason to deviate from that in this PR's changes.

@AnningCheng-NOAA
Copy link
Copy Markdown
Contributor

approved.

@climbfuji
Copy link
Copy Markdown
Collaborator

This PR was pulled into #795. It will be merged (and automatically closed) when #795 gets merged.

Update. This PR was removed again from #795, because it led to crashes with GSL physics when Thompson MP was used (in DEBUG and PROD mode, both with GNU and Intel). These issues need to be addressed separately to not hold up the original PR from @gthompsnWRF.

@grantfirl
Copy link
Copy Markdown
Collaborator

grantfirl commented Dec 10, 2021

I reset the code review approvals due to the crashes so that this will be blocked from being merged as-is (in addition to the added label -- does that actually prevent merging?)

Copy link
Copy Markdown
Collaborator

@climbfuji climbfuji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR needs to be fixed, because the proposed changes do not work with the GSL physics (segmentation faults in the regression tests). The cnvw_in array (which is in phy_f3d) isn't available for Thompon MP. I am not sure how this worked for @RuiyuSun. Also, this array isn't going into the restart files when Thompson MP is used, regardless of the rest of the physics, therefore breaking restart reproducibility.

@RuiyuSun and I will be working on this PR next week.

@climbfuji climbfuji removed the bug label Dec 16, 2021
@climbfuji
Copy link
Copy Markdown
Collaborator

@RuiyuSun please check carefully that I resolved the merge conflicts in physics/radiation_clouds.f correctly: https://github.com/NCAR/ccpp-physics/pull/789/files/ - thanks!

Copy link
Copy Markdown
Contributor

@gthompsnWRF gthompsnWRF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, I have no problems with the changes, but do have some pretty simple questions and ideas to mention.

Comment thread physics/radiation_clouds.f Outdated
! real (kind=kind_phys), parameter :: xrc3 = 200.
real (kind=kind_phys), parameter :: xrc3 = 100.
real (kind=kind_phys), parameter :: xrc3 = 200.
! real (kind=kind_phys), parameter :: xrc3 = 100.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why we need to keep the old value of xrc3 in a comment. From doing git differences of versions, this can be detected pretty easily. Furthermore, this constant is used (I think) in only a single line of code, so is it really needed as a declared variable at all?

do k = 1, NLAY
do i = 1, IX
clwf(i,k) = clw(i,k,ntcw) + clw(i,k,ntiw) + clw(i,k,ntsw)
& + clw(i,k,ntrw) + cnvw(i,k)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really agree that rain water should be used in a sum of so-called "cloud" species. Rain is not radiatively important to RRTMG anyway. What is being permitted here is the idea that rain contributes to cloud fraction. For what reason? I can describe a scenario with fast moving upper clouds causing snow that falls to a melting layer becoming rain and having zero cloud above it. While you might say this is splitting hairs, as we get to higher and higher resolution that would imply rain with no cloud above still produces a non-zero cloud cover. I am just saying that rain can horizontally separate from the clouds that produced it (in the vertical sense).

Comment thread physics/radiation_clouds.f Outdated
crp(i,k) = max(0.0, clw(i,k,ntrw) * gfac * delp(i,k))
csp(i,k) = max(0.0, (clw(i,k,ntsw)+clw(i,k,ntgl)) * &
& gfac * delp(i,k))
! csp(i,k) = max(0.0, (clw(i,k,ntsw)+clw(i,k,ntgl)) * &
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Graupel was removed, thank you. But I still wonder why we need the old line of code commented out rather than eliminated.

Comment thread physics/radiation_clouds.f Outdated
do k = 1, NLAY-1
do i = 1, IX
clwt = 1.0e-6 * (plyr(i,k)*0.001)
! clwt = 1.0e-6 * (plyr(i,k)*0.001)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment. Do we now need multiple commented out lines when a single scalar value has been changed? I suggest deleting commented lines.

Comment thread physics/radiation_clouds.f Outdated
if (.not. lmfshal) then
tem1 = min(max(sqrt(sqrt(onemrh*qstl(i,k))),0.0001),1.0)
tem1 = 2000.0 / tem1
if(rhly(i,k) > 1.) then
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will make a strong point of caution here. This line is saying that if Relative Humidity is greater than 100%, then we have 100% cloud coverage. Firstly, in water cloud conditions RH is likely to be machine-precision close to 1.0, but not assured. That might mean RH is numerically 0.99* (many digits of 9). I didn't run through the rest of the lines of code, but if cloud water mixing ratio is something like 1.E-3 (kg/kg; that's pretty big), does that assure a cloud fraction = 100%?

Furthermore, what RH function is being used here below T=0C? Is it the RH with respect to ice or some blend of RH-water and RH-ice? My concern here is that when RH-ice is 101% then result is 100% cloudy, but I can assure you that the real atmosphere is not always cloudy in those conditions. It often takes a lot of ice supersaturation to nucleate the ice crystals. So in the circumstance of RH-ice=105% and the explicit microphysics is making no ice (due to reason above), then do you really want to assume 100% cloudy? If this variable rhly is strictly RH-water, then my point is moot.

Comment thread physics/radiation_clouds.f Outdated
tem1 = 2000.0 / tem1
if(rhly(i,k) > 1.) then
cldtot(i,k) = 1.
else
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the prev version of progcld6, you removed the test of whether or not lmfshal is true/false, so there is a different calculation of tem1. I am noting it just to be sure that was intended and not skipped by mistake.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope that this was not a result of me resolving the merge conflicts incorrectly. All other merge conflicts I think I got right.

Comment thread physics/radiation_clouds.f Outdated
@grantfirl
Copy link
Copy Markdown
Collaborator

@RuiyuSun @yangfanglin Since there is a high priority to get this merged, we have this at the top of the ccpp-physics queue. Do you want to merge this PR as-is or pause to make changes from Greg's comments? A third alternative is to merge as-is and add issues to followup with later, of course.

@RuiyuSun
Copy link
Copy Markdown
Contributor Author

RuiyuSun commented Dec 17, 2021 via email

@yangfanglin
Copy link
Copy Markdown

yangfanglin commented Dec 17, 2021

@RuiyuSun Ruiyu, please remove those commented lines. Some of the scientific questions Greg raised can be addressed later. I think in GFS RH is blended for temperatures between -25 or lower and 0. Would it be possible to make a couple of back to the envelop plots to show the GFS version of Xu&Randall cloud fraction as a function of RH and q (both water and ice), similar to Figs 2 and 3 found in https://armweb0-stg.ornl.gov/publications/proceedings/conf09/extended_abs/lazarus1_sm.pdf ? Xu&Randall scheme was developed with "large-scale" grid averaged water and ice condensates and "large-scale" grid average RH.

@RuiyuSun
Copy link
Copy Markdown
Contributor Author

RuiyuSun commented Dec 17, 2021 via email

Update cloud_cover_xr with latest change from NCAR ccpp-physics main
@yangfanglin
Copy link
Copy Markdown

@RuiyuSun Try this link https://armweb0-stg.ornl.gov/publications/proceedings/conf09/extended_abs/lazarus1_sm.pdf . I will send you the PDF file by email as well.

@climbfuji climbfuji merged commit 84654b7 into NCAR:main Dec 20, 2021
@climbfuji climbfuji mentioned this pull request Dec 29, 2021
JohanaRomeroAlvarez pushed a commit to JohanaRomeroAlvarez/ccpp-physics that referenced this pull request Sep 8, 2025
* "point to the physics update for RRFS.v1 code freeze"

* add zero-sized allocation to fix -check all runtime errors

---------

Co-authored-by: Haiqin.Li <Haiqin.Li@noaa.gov>
Co-authored-by: Jong Kim <jong.kim@noaa.gov>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

modification of cloud cover calculation and adding namelist options to Thompson MP

7 participants