Skip to content
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

Merged
merged 106 commits into from
Dec 13, 2021

Conversation

climbfuji
Copy link
Collaborator

@climbfuji climbfuji commented Dec 1, 2021

This PR contains

  • a metadata bug fix and a bug fix for a sign error in UGWP - this is urgently needed in the authoritative repositories
  • major updates to GF convection, including a small change for the radiation coupling when GF convection is used with GFDDL-MP
  • updates to RUC LSM, MYNN SFC, MYNN PBL
  • updates to GFS_debug.F90 to include newly added variables and recently removed variables

Associated PRs:

NOAA-EMC/fv3atm#435
ufs-community/ufs-weather-model#937

For testing, see ufs-community/ufs-weather-model#937

joeolson42 and others added 30 commits June 22, 2021 01:38
…hysics into gsl_develop_hannah_and_joe_changes_combined_20210712
…hysics into gsl_develop_hannah_and_joe_changes_combined_20210712
 into gsl_develop_hannah_and_joe_changes_combined_20210712
…hysics into gsl_develop_hannah_and_joe_changes_combined_20210712
 into gsl_develop_hannah_and_joe_changes_combined_20210712
… physics/cu_gf_driver.F90 to achieve b4b identical results in restart runs
…changes_combined_20210712

Wrapper PR for NCAR#97 (Update of GF aerosol treatment and tunings) and NCAR#98 (Updates to MYNN-EDMF)
@climbfuji climbfuji marked this pull request as ready for review December 3, 2021 14:10
@climbfuji climbfuji changed the title DRAFT - Merge NOAA-GSL gsl/develop into main Merge NOAA-GSL gsl/develop into main (update GF CU, MYNN SFC/PBL, RUC LSM, bug fixes in UGWP) Dec 3, 2021
else
! MYNN sub-grid cloud fraction
cldcov(i,k1) = clouds1(i,k1)
endif
enddo
enddo
elseif (imfdeepcnv == imfdeepcnv_gf .and. kdt>1) THEN
Copy link
Collaborator

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?

Copy link
Collaborator

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

Copy link
Collaborator

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.

Copy link
Collaborator

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.

! 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))
Copy link
Collaborator

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?

Copy link
Collaborator

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

@@ -301,6 +322,14 @@
type = real
kind = kind_phys
intent = in
[aod_gf]
standard_name = aod_gf_deep
Copy link
Collaborator

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)?

Copy link
Collaborator

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.

Copy link
Collaborator

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).

Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

@climbfuji
Copy link
Collaborator Author

@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!

@@ -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
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
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.

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!

@climbfuji
Copy link
Collaborator Author

@grantfirl @hannahcbarnes I addressed the reviewer comments for the gsl/develop update in 83ff129. Please check the changes, especially the change in the if-then-else logic in the RRTMG pre code. Thanks!

@climbfuji
Copy link
Collaborator Author

@yangfanglin This PR contains the bug fix for the sign error in physics/drag_suite.F90. It's been merged just now.

@climbfuji climbfuji merged commit 4865cba into NCAR:main Dec 13, 2021
@yangfanglin
Copy link
Collaborator

yangfanglin commented Dec 13, 2021 via email

@climbfuji climbfuji deleted the update_gsl_global_and_regional_tests branch June 27, 2022 03:00
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.

8 participants