-
Notifications
You must be signed in to change notification settings - Fork 153
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
Merge NOAA-GSL gsl/develop into main (update GF CU, MYNN SFC/PBL, RUC LSM, bug fixes in UGWP) #791
Merge NOAA-GSL gsl/develop into main (update GF CU, MYNN SFC/PBL, RUC LSM, bug fixes in UGWP) #791
Conversation
…changes by trial and error...
…changes by trial and error...
…hysics into gsl_develop_hannah_and_joe_changes_combined_20210712
…hysics into gsl_develop_hannah_and_joe_changes_combined_20210712
Minor code clean up
…hysics into gsl_develop_hannah_and_joe_changes_combined_20210712
…ysics/cu_gf_driver_pre.meta
… physics/cu_gf_driver.F90 to achieve b4b identical results in restart runs
…b.com/climbfuji/ccpp-physics into update_gsl_develop_from_main_20210721
physics/GFS_rrtmg_pre.F90
Outdated
else | ||
! MYNN sub-grid cloud fraction | ||
cldcov(i,k1) = clouds1(i,k1) | ||
endif | ||
enddo | ||
enddo | ||
elseif (imfdeepcnv == imfdeepcnv_gf .and. kdt>1) THEN |
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.
I'm confused by this logic. Can't this condition and the condition above (do_mynnedmf) both be true simultaneously? If so, I'm not sure an IF/ELSEIF is the best way to handle this. Am I missing something?
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.
If MYNN is present , then it takes care of everything (ie: it acounts for all subgrid clouds in MYNN and GF). If GF is called and MYNN is not present, the subgrid clouds in GF must be account for separately (since they are not accounted for in GFDL microphysics) This is why the elseif imfdeepcnv_gf is present and why it is listed after the if MYNN statement.
If you can come up with better logic I am open
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.
OK, so I definitely was missing some information. Your solution obviously works for the use case, I'm just wondering if there is a clearer way to write it (that won't be interpreted as a bug by subsequent folks reading the code). What about nesting IF's?
if ((imfdeepcnv == imfdeepcnv_gf .or. do_mynnedmf) .and. kdt>1) then
if (do_mynnedmf) then
!calculate cldcov for MYNN
else
!calculate cldcov for GF
endif
else
!rest of options
endif
I don't know if this is any clearer or not. It's less efficient since you're testing for do_mynnedmf twice, but that is probably insignificant. @climbfuji opinions? We could always leave it as-is and maybe putting in a comment explaining things would be sufficient.
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.
I agree, the logic in this part of the code is weird and should be made more clear. I am good with your suggested code change.
physics/cu_gf_deep.F90
Outdated
! prop_c=.9/aeroadd | ||
aeroadd=0. | ||
if((psumh(i)>0.).and.(psum2(i)>0.))then | ||
aeroadd=((1.e-2*ccnclean)**beta3)*((psumh(i)*1.e0)**(alpha3-1)) |
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.
Why are we multiplying by 1e.0 in this line and 2459? Is this a placeholder to be changed in the future or something?
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.
You can remove the 1e.0
physics/cu_gf_driver.meta
Outdated
@@ -301,6 +322,14 @@ | |||
type = real | |||
kind = kind_phys | |||
intent = in | |||
[aod_gf] | |||
standard_name = aod_gf_deep |
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.
We should use "aerosol_optical_depth" rather than "aod". The standard names aerosol_optical_depth_for_shortwave_bands_01_16 and aerosol_optical_depth_for_longwave_bands_01_16 already exist. How does this new variable relate? Is it for all radiation bands? Is there a reason that this is specific to GF (could it potentially be used in other schemes)?
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.
This is a specific variable used for only GF. It is not related to aerosol_optical_depth_for_shortwave_bands_01_16 or aerosol_optical_depth_for_longwave_bands_01_16. It is not for radiation bands, it is used as a measure of pollution in the atmosphere. GF is aerosol-aware, which is why it is needed. SAS is also aerosol-aware, but I have not looked close enough into the details of that scheme to see if they would use this.
You could rename it as aerosol_optical_depth_gf. You can also provide additional suggestions if you wish.
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.
I'm thinking that we can just use aerosol_optical_depth full stop. According to the standard name rules (link), we shouldn't add qualifiers like _gf if they aren't absolutely necessary. That way if, say, SAS or any other convective scheme wanted to reuse this variable for their purposes or the same purpose, there wouldn't necessarily be a need to add a new variable (and therefore the memory footprint stays the same).
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.
I am worried about that since people may get confused with aerosol optical depth used in other parts of the code, such as in the radiation. This variable should absolutely not be used in radiation. The name needs to be at least somewhat specific.
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.
I agree.
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.
@climbfuji agree with what? The need to qualify or trying to keep it general? If it shouldn't be used for radiation, we could qualify that it is to be used in convection schemes. That would at least be more general than saying that only GF can use it?
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.
I agree with Hannah that it needs to be made clear that this is specific to GF (I don't even know if it is compatible with any other convection scheme, but if it is, then it would be better to express it in the standard name). We do have other such cases in CCPP, of course, where we have adopted standard names w/o qualifier. One example being the water/ice friendly aerosols that, in the current representation can only be used by Thompson MP. Of course, if Thompson is not used, than anybody else can use those variables the way they want, but a developer finding aerosols somewhere and thinking that he or she can just use it will run into trouble.
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.
OK, you both have convinced me. :) To be consistent with existing standard names spelling out GF, how about let's settle on aerosol_optical_depth_for_grell_freitas_deep_convection? Definitely longer, but consistent with others.
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.
Heureka! Good with me. I'll make the change along with others over the weekend.
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.
Thanks, this good with me as well.
@hannahcbarnes @haiqinli @joeolson42 Please take note of the comments that @grantfirl left and let me know if you have any suggestions/changes you wish to make. Thanks! |
physics/module_bl_mynn.F90
Outdated
@@ -490,7 +519,7 @@ SUBROUTINE mym_initialize ( & | |||
INTEGER :: k,l,lmax | |||
REAL :: phm,vkz,elq,elv,b1l,b2l,pmz=1.,phh=1.,flt=0.,flq=0.,tmpq | |||
REAL :: zi | |||
REAL, DIMENSION(kts:kte) :: theta | |||
REAL, DIMENSION(kts:kte) :: theta,thetav,thlsg,qwsg |
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.
Silly, but for readability, consider removing the whitespace change so that var declarations align.
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.
I agree. It's definitely meant to be aligned. I probably fat-fingered a couple spaces without noticing.
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.
I'll fix it together with some other changes that were requested.
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.
I will not pretend to understand all of the code changes represented here, but I've commented on anything unclear that I've detected. Thanks to all the developers of these schemes and nice work!
…te_gsl_global_and_regional_tests
causing cold/moist bias.
…/ccpp-physics into update_gsl_global_and_regional_tests
…te_gsl_global_and_regional_tests
…te_gsl_global_and_regional_tests
@grantfirl @hannahcbarnes I addressed the reviewer comments for the gsl/develop update in 83ff129. Please check the changes, especially the change in the |
@yangfanglin This PR contains the bug fix for the sign error in |
Thanks, Dom.
…Sent from my iPhone
On Dec 13, 2021, at 7:55 AM, Dom Heinzeller ***@***.***> wrote:
@yangfanglin This PR contains the bug fix for the sign error in physics/drag_suite.F90. It's been merged just now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
This PR contains
GFS_debug.F90
to include newly added variables and recently removed variablesAssociated PRs:
NOAA-EMC/fv3atm#435
ufs-community/ufs-weather-model#937
For testing, see ufs-community/ufs-weather-model#937