-
Notifications
You must be signed in to change notification settings - Fork 146
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
Redundant surface variable cleanup #659
Conversation
…_temperature_over_ice
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 looking good! A couple of changes (mainly reversing whitespace changes), please. Hopefully all regression tests pass on Hera with both compilers.
physics/GFS_surface_composites.F90
Outdated
snowd_lnd(i) = snowd(i) | ||
semis_lnd(i) = semis_rad(i) | ||
qss_lnd(i) = qss(i) | ||
hflx_lnd(i) = hflx(i) | ||
qss_lnd(i) = qss(i) |
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.
Please revert indentation changes in lines 198 and 199
physics/GFS_surface_composites.F90
Outdated
@@ -209,8 +206,7 @@ subroutine GFS_surface_composites_pre_run (im, lkm, frac_grid, flag_cice, cplflx | |||
if (icy(i)) then ! Ice | |||
uustar_ice(i) = uustar(i) | |||
weasd_ice(i) = weasd(i) | |||
tsfc_ice(i) = tisfc(i) | |||
tsurf_ice(i) = tisfc(i) | |||
tsfci(i) = tisfc(i) |
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.
Same here, =
were aligned previously.
physics/GFS_surface_composites.F90
Outdated
evap(i) = evap_ice(i) | ||
hflx(i) = hflx_ice(i) | ||
qss(i) = qss_ice(i) | ||
tisfc(i) = tice(i) | ||
if (.not. flag_cice(i)) then | ||
! tisfc(i) = tice(i) ! over lake ice (and sea ice when uncoupled) | ||
zorl(i) = cice(i) * zorli(i) + (one - cice(i)) * zorlo(i) | ||
tsfc(i) = tsfc_ice(i) ! over lake (and ocean when uncoupled) | ||
tsfc(i) = tsfci(i) ! over lake (and ocean when uncoupled) | ||
|
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.
Please remove extra blank line
@@ -27,7 +27,7 @@ end subroutine GFS_surface_generic_pre_finalize | |||
!! | |||
subroutine GFS_surface_generic_pre_run (im, levs, vfrac, islmsk, isot, ivegsrc, stype, vtype, slope, & | |||
prsik_1, prslk_1, tsfc, phil, con_g, & | |||
sigmaf, soiltyp, vegtype, slopetyp, work3, tsurf, zlvl, & | |||
sigmaf, soiltyp, vegtype, slopetyp, work3, zlvl, & |
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 change has been made in a previous PR (#627 I think), you will see the merge conflict when you update your code.
@@ -187,7 +187,7 @@ subroutine sfc_noah_wrfv4_pre_run (im, nsoil, ialb, isice, land, & | |||
if (land(i) .and. flag_guess(i)) then | |||
weasd_save(i) = weasd(i) | |||
snwdph_save(i) = snwdph(i) | |||
tsfc_save(i) = tsfc(i) | |||
!mz tsfc_save(i) = tsfc(i) |
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.
Please delete instead of commenting out if really not needed (did you check the gsd diag 3d test)?
@@ -738,7 +738,7 @@ subroutine sfc_noah_wrfv4_post_run (im, nsoil, land, flag_guess, flag_lsm, & | |||
if (flag_guess(i)) then | |||
weasd(i) = weasd_save(i) | |||
snwdph(i) = snwdph_save(i) | |||
tsfc(i) = tsfc_save(i) | |||
!mz tsfc(i) = tsfc_save(i) |
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.
Same here, pease delete instead of commenting out if really not needed.
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 looks good to me, thanks for updating the formatting. I will combine this PR with other PRs, so that you don't have to keep updating the PRs from main all the time.
@mzhangw I just discovered that the changes in your PR lead to situations where you are passing the SAME variable (i.e. same standard name) to the scheme twice with different local name. That is forbidden, not just by CCPP but also by Fortran standards. See for example sfc_nst and sfc_drv_ruc. I'll fix that in my effort to bring it up to date with the current code and combine it with Xia's changes. |
I also get those errors from the host model variable definitions:
Will work on it. |
Thanks!
…On Fri, Jul 23, 2021 at 8:47 AM Dom Heinzeller ***@***.***> wrote:
I also get those errors from the host model variable definitions:
ERROR: Multiple definitions of standard_name surface_longwave_emissivity_over_ice in type/variable defintions
Will work on it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#659 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG7TW2T7IZJLYLKWNGRS4W3TZF6IRANCNFSM45BIHLHQ>
.
|
I actually don't understand how this code compiled, ran and verified against the existing baselines. The metadata parser immediately threw errors about duplicate standard names in several ccpp-physics routines. I don't remember adding this check recently, but maybe I did. |
It did pass all RTs a while ago. I will take a look at it again today if it
is ok with you. Sitting at Dr. office now.
…On Fri, Jul 23, 2021 at 11:20 AM Dom Heinzeller ***@***.***> wrote:
I actually don't understand how this code compiled, ran and verified
against the existing baselines. The metadata parser immediately threw
errors about duplicate standard names in several ccpp-physics routines. I
don't remember adding this check recently, but maybe I did.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#659 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG7TW2QNZQ2IVEGZ72HLPDLTZGQF3ANCNFSM45BIHLHQ>
.
|
Recent code update causes some conflicts with this PR. I need revisit this PR. |
Thanks, agreed. The code should never have compiled or run. Passing the same variable twice to a subroutine is dangerous and can have bad consequences. This PR is therefore on hold until the issues are resolved. Thanks for working on it, and sorry for not catching the problems in the first review (GitHub diff view isn't any good for this type of changes). |
The PRs did pass all RTs back in May (See my attached log). However, the
surface codes have been updated significantly since then. It won't hurt to
revisit it with new updates.
…On Thu, Jul 29, 2021 at 8:53 AM Dom Heinzeller ***@***.***> wrote:
Thanks, agreed. The code should never have compiled or run. Passing the
same variable twice to a subroutine is dangerous and can have bad
consequences. This PR is therefore on hold until the issues are resolved.
Thanks for working on it, and sorry for not catching the problems in the
first review (GitHub diff view isn't any good for this type of changes).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#659 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG7TW2WGQXVXZ7CMUS726IDT2FTQHANCNFSM45BIHLHQ>
.
|
Even if they passed, the code was incorrect. You are not allowed to pass the same variable (e.g. same standard name) twice to a Fortran function or subroutine. Fortunately, the CCPP framework now catches these errors. |
This PR will be replaced with a new one. |
This effort is to address the issue.
Associated PR: NOAA-EMC/fv3atm#317