-
Notifications
You must be signed in to change notification settings - Fork 37
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
Remove warnings from CCPP physics #169
Remove warnings from CCPP physics #169
Conversation
…bles not given an explicit value" warning. The following table provides justification for setting the variable to 0, it is how they are treated in other places. | file | line | description | |--------------------+------+-----------------------------| | ugwpv1_gsldrag.F90 | 521 | zlwb(:)= 0. ; zogw(:)=0. | | ugwp_driver_v0.F | 206 | zmtb(i) = 0.0 | | cires_ugwp.F90 | 297 | if (do_ugwp) zlwb(:) = 0. |
… drain_cpl and dsnow_cpl vars are changed from intent(out) to intent(in) variables. This is to replicate the rain_cpl and snow_cpl variables.
…out) variables. Variable err_message will report any errors in open and read statements
…eir related meta files
@Qingfu-Liu would you please create a UFS WM PR for this? |
Supercedes #149 |
@Qingfu-Liu @junwang-noaa I'll run RTs for this alone to verify behavior. Then, assuming no BL changes, I'd like to see it combined with #150, which also doesn't change BLs. |
OK, RTs are all successful. I'm going to ask Dom to combine this with #150 for final tests/merge. |
@junwang-noaa and @grantfirl Since this PR#169 is merged to PR#150, I am not sure who should create a UFS WM PR for PR#150? |
@Qingfu-Liu I see Dom already created a ufs wm PR#2066. |
@junwang-noaa Thanks for the information. |
Most credit to @scrasmussen. @Qingfu-Liu removed some unneeded variables.
Description of Changes:
Changes to get rid of all the warnings, as pointed out in ufs-weather-model Issue#1984. The fixes for the second and third bullet points were intuited from how similar variables are treated in the code base, if different behavior is preferred please let me know!
For all the
warning #5462: Global name too long, shortened from
warnings: this issue may be already fixed by the Intel compiler, per their message board. I haven't had access to the newer Intel 2024.0.1 or 2024.0.2 versions to test.The
drain_cpl
anddsnow_cpl
warnings were "explicit INTENT(OUT) declaration is not given an explicit value". These variables are changed from intent(out) to intent(in) variables. This is to replicate the rain_cpl and snow_cpl variables.The
err_message
return value of two functions were not defined. The error message is defined as "" and if an error occurs in theopen
andwrite
statements it will return the error message. Note: this doesn't have the additionalerrflg
, as stated in the coding rules, figure that would be an issue for a different PR if we want it fixed?The last remaining warning message still needs to be fixed. It is
FV3/ccpp/physics/physics/dcyc2t3.f(184): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [ADJSFCULW]
. This is only used in a print statement; removed [ADJSFCULW]Tests Conducted:
Testing on Derecho with Intel Fortran 2023.2.1. Result of testing is as follows:
Dependencies:
None
Documentation:
No changes.
Issue (optional):
Fixes most issues mentioned in ufs-weather-model Issue#1984.