-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HR4 and SFS baseline update: Improve convection/radiation interaction in the GFS physics suite #216
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sigmab is used for the prognostic sigma parameterization. Is there any reason why sigmaout rather than sigmab is used for cnvw calculation?
Also, to generalize cnvw calculation even for progsigma=.F., it would be better to code as:
if (progsigma) then
cnvw=sigmaout (or sigmab) * cnvw
else
cnvw= sigmagfm(i) * cnvw
endif
Hi Jongil, the reason I chose sigmaout was because it is a 3D array containing sigma, and sigmab is the 2D array tuned to the cloud-base value (using the beta* parameters) for the cloudbase massflux. Therefore sigmab is smaller than sigmaout, and I think it will cause too little convective cloud condensate from deep convection at 13 km resolution. Thank you for the suggestion on using progsigma flag, I will make that correction. I think for SFS, we can use progsigma = true, because the closure will still be the AS cloud work-function closure due to a resolution check. |
@lisa-bengtsson In the code, I don't see that sigmaout varies vertically. It is vertically constant, same as sigmab. After sigmaout is assigned with vertically constant sigmab, sigmab is divided by betascu, betamcu, or betadcu and so become smaller. Am I misunderstanding? |
@JongilHan66 That is correct. The difference is not necessarily a 3D vs 2D array, but rather that sigmab is smaller than sigmaout after tuning the closure. It would lead to a larger positive bias in SW down in deep cu regions based on our tests. I could check sensitivity to this for the June case if you would like? |
@lisa-bengtsson Thanks. I don't think further test is necessary. |
@lisa-bengtsson do you have column integrated cloud water now from vsdb now? Thanks! |
@RuiyuSun It is quite interesting, in the region of shallow cu in Eastern Pacific, CWAT is largely impacted of both these changes, in different directions. |
@lisa-bengtsson Thanks Lisa. statocumulus in EP is quite sensitive to background diffusivity. ` |
Would this also make it into the next EP experiments for GEFS? |
Hi, @grantfirl . Regression testing is complete on WM PR-2340. Feel free to merge this ccpp-physics PR for us. |
Issue:
ufs-community/ufs-weather-model#2339
This update is a collaboration between PSL, EMC, GSL, and DTC (@lisa-bengtsson, @JongilHan66 , @yangfanglin , @RuiyuSun , Weiwei Li and Shan Sun)
The GFS physics suite at 100km yields too large cloud cover and optical depth, causing too much cloud shielding and a drift in Sea Surface Temperatures, SST for seasonal prediction. This is an issue for the Seasonal Forecast System baseline. The issue was identified to be related to too much convective cloud condensate passed in from the cumulus convection scheme.
A scale adaptive solution is proposed and tested for SFS and GFS resolutions, outputting updraft values of in-cloud condensate. We propose to add this change to SFS baselines as well as the HR4 prototype of the GFS. In testing we also tune the minimum background diffusivity in the inversion layer near the PBL top (xkinv1) from xkinv1=0.4 to xkinv1=0.15 in order to not reduce convective clouds too much in marine stratocumulus.
See presentation here: https://docs.google.com/presentation/d/11hP81jcBO2HZ1y4QOkBvwVOBqaPjw6cZUg-2JWF0FzI/edit#slide=id.g2e178e73b20_0_152