-
Notifications
You must be signed in to change notification settings - Fork 150
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
fix diagnostic PBL and convective tendencies #489
Conversation
…NPBL_wrapper.F90, ysuvdif.F90, shinhongvdif.F90
Addresses #490 |
Diagnostic tendencies before the fix for the TWPICE case: Same for the ARM_SGP_summer_1997_A case: |
Diagnostic tendencies AFTER the fix for the TWPICE case: Same for the ARM_SGP_summer_1997_A case: |
Note to self: Check other non-operational PBL schemes: satmedmfvdif (non-Q version), SHOC, MYJ |
@SamuelTrahanNOAA Since you did the original implementation, could you please take a look at this PR that extends and fixes the tendencies output? |
Do the tendencies of each tracer for all schemes add up to the total physics tendency for each tracer? Plotting the diagnostic tendencies doesn't prove anything. If the physics scheme itself was broken, then the ugly diagnostic tendencies may have been an accurate representation of the scheme's incorrect tendencies. |
…en't already doing so
… diagnostic calculation outside of loops
@SamuelTrahanNOAA While it's true that plotting just the PBL tendencies before and after a fix doesn't "prove" anything, a look at the "before" plots does point out that 1) several schemes do not calculate PBL tendencies and 2)some that do produce tendencies don't make sense and warrant a look at the code. After said look at the code, it was obvious that there were several issues in the calculation of the actual diagnostic, not necessarily the scheme behavior. For example, the moninedmf scheme was incorrectly dividing by timestep twice, that the moninedmf and MYNN schemes were erroneously subtracting out changes due to radiation in the T-tendencies, and that the operational scheme was erroneously multiplying by a scalar parameter related to TKE-dissipative heating in both the T- and q-tendencies. The "after" plots show non-zero tendencies for schemes where I added code to calculate tendencies, and the tendencies look physically realistic, for the most part. But, like you said, this is progress, not proof. Following your suggestion, I went to plot a residual for u, v, T, and qv tendencies defined by: X_res = X_phys - (X_scheme1 + X_scheme2 + ... + X_schemeN) where X represents the tendency of u, v, T, or qv, the X_phys term represents the tendency due to all physics processes, and X_schemeY is the tendency due to process Y. Unfortunately, this doesn't help because X_phys is defined in the new phys_tend.F90 as: X_phys = X_scheme1 + X_scheme2 + ... + X_schemeN IMO, this formulation hides errors if any of X_schemeY is in error. If the X_phys terms were instead calculated as: X_phys = X1-X0 where X0 is the value of X saved at the beginning of physics, and X1 is the value of X saved at the end of physics. I switched to this formulation and then plotted X_res for a given case for the original (buggy) code: profiles_mean_dq_dt_residual.pdf I repeated the plots after the PBL tendency fixes: profiles_mean_dq_dt_residual.pdf Looking good, except for the GSD suite now. The profile of the residual points to the convective scheme, so I looked in cu_gf_driver.F for the G-F convective scheme and found another bug. The diagnostic tendencies lacked the same multipliers found in the code when the state is actually updated. Adding these in, I now get the following residuals: profiles_mean_dq_dt_residual.pdf Again, looking better. The residuals are continually shrinking as bugs are found. The method appears to work. At this point, I can identify that the remaining qv-tendency residual is due to a positive-definite statement for qv when qv is updated. The other residuals are unknown at this point. @ligiabernardet Do you think that it makes sense to continue tracking down these residuals in the tendencies until they are all acceptably close to 0, or are they close enough as they are? IMO, the last set of plots show that the tendency errors have been reduced by several orders of magnitude and that they can likely safely be used at this point. It might be worth tracking down, just to understand where the remaining residuals are coming from. |
This has been a vast improvement and as soon as there is an opportunity we
should commit it. Further investigation can continue.
…On Wed, Aug 19, 2020 at 5:55 PM grantfirl ***@***.***> wrote:
Do the tendencies of each tracer for all schemes add up to the total
physics tendency for each tracer?
Plotting the diagnostic tendencies doesn't prove anything. If the physics
scheme itself was broken, then the ugly diagnostic tendencies may have been
an accurate representation of the scheme's incorrect tendencies.
@SamuelTrahanNOAA <https://github.com/SamuelTrahanNOAA> While it's true
that plotting just the PBL tendencies before and after a fix doesn't
"prove" anything, a look at the "before" plots does point out that 1)
several schemes do not calculate PBL tendencies and 2)some that do produce
tendencies don't make sense and warrant a look at the code. After said look
at the code, it was obvious that there were several issues in the
calculation of the actual diagnostic, not necessarily the scheme behavior.
For example, the moninedmf scheme was incorrectly dividing by timestep
twice, that the moninedmf and MYNN schemes were erroneously subtracting out
changes due to radiation in the T-tendencies, and that the operational
scheme was erroneously multiplying by a scalar parameter related to
TKE-dissipative heating in both the T- and q-tendencies.
The "after" plots show non-zero tendencies for schemes where I added code
to calculate tendencies, and the tendencies look physically realistic, for
the most part. But, like you said, this is progress, not proof.
Following your suggestion, I went to plot a residual for u, v, T, and qv
tendencies defined by:
*X_res = X_phys - (X_scheme1 + X_scheme2 + ... + X_schemeN)*
where X represents the tendency of u, v, T, or qv, the X_phys term
represents the tendency due to all physics processes, and X_schemeY is the
tendency due to process Y. Unfortunately, this doesn't help because X_phys
is defined in the new phys_tend.F90 as:
*X_phys = X_scheme1 + X_scheme2 + ... + X_schemeN*
IMO, this formulation hides errors if any of X_schemeY is in error. If the
X_phys terms were instead calculated as:
*X_phys = X1-X0*
where X0 is the value of X saved at the beginning of physics, and X1 is
the value of X saved at the end of physics. I switched to this formulation
and then plotted X_res for a given case for the original (buggy) code:
profiles_mean_dq_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099847/profiles_mean_dq_dt_residual.pdf>
profiles_mean_dT_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099850/profiles_mean_dT_dt_residual.pdf>
profiles_mean_du_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099851/profiles_mean_du_dt_residual.pdf>
profiles_mean_dv_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099853/profiles_mean_dv_dt_residual.pdf>
I repeated the plots after the PBL tendency fixes:
profiles_mean_dq_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099863/profiles_mean_dq_dt_residual.pdf>
profiles_mean_dT_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099864/profiles_mean_dT_dt_residual.pdf>
profiles_mean_du_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099865/profiles_mean_du_dt_residual.pdf>
profiles_mean_dv_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099866/profiles_mean_dv_dt_residual.pdf>
Looking good, except for the GSD suite now. The profile of the residual
points to the convective scheme, so I looked in cu_gf_driver.F for the G-F
convective scheme and found another bug. The diagnostic tendencies lacked
the same multipliers found in the code when the state is actually updated.
Adding these in, I now get the following residuals:
profiles_mean_dq_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099875/profiles_mean_dq_dt_residual.pdf>
profiles_mean_dT_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099876/profiles_mean_dT_dt_residual.pdf>
profiles_mean_du_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099878/profiles_mean_du_dt_residual.pdf>
profiles_mean_dv_dt_residual.pdf
<https://github.com/NCAR/ccpp-physics/files/5099879/profiles_mean_dv_dt_residual.pdf>
Again, looking better. The residuals are continually shrinking as bugs are
found. The method appears to work. At this point, I can identify that the
remaining qv-tendency residual is due to a positive-definite statement for
qv when qv is updated. The other residuals are unknown at this point.
@ligiabernardet <https://github.com/ligiabernardet> *Do you think that it
makes sense to continue tracking down these residuals in the tendencies
until they are all acceptably close to 0, or are they close enough as they
are? IMO, the last set of plots show that the tendency errors have been
reduced by several orders of magnitude and that they can likely safely be
used at this point. It might be worth tracking down, just to understand
where the remaining residuals are coming from.*
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#489 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE7WQATNDFG632XJYCDZNUDSBRQ4ZANCNFSM4QEIZCGA>
.
|
OK, I'm regression testing this now. (minus WW3 tests that are not compiling) |
This passed all regression tests except for the expected one: fv3_ccpp_gsd_diag3d_debug (the diagnostic tendencies have been corrected) The tests with WW3=Y have been skipped due to ufs-community/ufs-weather-model#189. I have no idea why I can't compile with WW3 but Jun seems to be able to fine. |
I'm re-running the WW3-based tests, now that there is a fix for ufs-community/ufs-weather-model#189 |
@grantfirl this PR is next in the commit queue. It will be combined with a small change from Moorthi for fv3atm. I will orchestrate the fv3atm PR, pulling in your changes and Moorthi's changes. But for this ccpp-physics PR, can I ask you to (a) update your code to the head of the master branch, and (b) make the following change, please?
Thanks! |
OK, I'm working on this now. |
@climbfuji Finished. |
Great, thank you. Will make this PR part of my ufs-weather-model and fv3atm PRs. |
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 for making the additional change in CMakeLists.txt
. I will merge the PR once all testing is done.
This PR fixes several tendencies within several different PBL schemes [hybrid EDMF, operational sa-moist-TKE-EDMF, MYNN, YSU, and Shin-Hong (AKA sa-YSU)]
Please see issue #490 for details on what was fixed.
Edit:
Associated PRs:
NOAA-EMC/GFDL_atmos_cubed_sphere#40
#489
NOAA-EMC/fv3atm#178
ufs-community/ufs-weather-model#208
For regression testing information, see ufs-community/ufs-weather-model#208.