-
Hello, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi Mike, Yes, this definitely an error, but currently a harmless one, I think. I noticed this a while ago and actually fixed it in the SCM repo, but the "frequency_for_diagnostic_clearing" section of metadata is superfluous and is not used in any ccpp-physics scheme. I'm pretty sure that it can be removed from the fv3atm version of GFS_typedefs.meta without any problem. I wonder if this needs to be raised as an issue in the ccpp-framework -- that it should flag an error during the cap generation stage when there are multiple versions of metadata for the same Fortran local variable. Perhaps the default behavior is just to associate both standard names with the same bit of memory. Although harmless in this case (since one standard name is never used in the physics), I can see how it might lead to hard-to-detect problems when debugging -- if you search for one standard name to see how a variable is passed around within a suite and assume that only schemes that modify the variable through one standard name, but the variable is actually being modified in another scheme by its "other" standard name, that might be a hard bug to track down. I'll put a discussion thread over there and reference this one. -Grant |
Beta Was this translation helpful? Give feedback.
Hi Mike,
Yes, this definitely an error, but currently a harmless one, I think. I noticed this a while ago and actually fixed it in the SCM repo, but the "frequency_for_diagnostic_clearing" section of metadata is superfluous and is not used in any ccpp-physics scheme. I'm pretty sure that it can be removed from the fv3atm version of GFS_typedefs.meta without any problem. I wonder if this needs to be raised as an issue in the ccpp-framework -- that it should flag an error during the cap generation stage when there are multiple versions of metadata for the same Fortran local variable. Perhaps the default behavior is just to associate both standard names with the same bit of memory. Although …