Redundant surface variable cleanup#659
Conversation
…_temperature_over_ice
climbfuji
left a comment
There was a problem hiding this comment.
This is looking good! A couple of changes (mainly reversing whitespace changes), please. Hopefully all regression tests pass on Hera with both compilers.
| 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.
Please revert indentation changes in lines 198 and 199
| 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.
Same here, = were aligned previously.
| 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.
Please remove extra blank line
| 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.
This change has been made in a previous PR (#627 I think), you will see the merge conflict when you update your code.
| 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.
Please delete instead of commenting out if really not needed (did you check the gsd diag 3d test)?
| 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.
Same here, pease delete instead of commenting out if really not needed.
climbfuji
left a comment
There was a problem hiding this comment.
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/ufsatm#317