Add standard name metadata to most EAMxx output variables

[AaronDonahue]

This commit brings EAMxx into CF-Compliance by adding standard_name metadata for a subset of the EAMxx output variables that have one.

Fixes #700

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce checks passing

Wonderful, this rule succeeded.

Make sure that checks are not failing on the PR, and reviewers approved

• #approved-reviews-by >= 1
• #changes-requested-reviews-by == 0
• any of:
  • all of:
    • check-success="gcc-openmp / dbg"
    • check-success="gcc-openmp / fpe"
    • check-success="gcc-openmp / opt"
    • check-success="gcc-openmp / sp"
  • check-skipped={% raw %}gcc-openmp / ${{ matrix.build_type }}{% endraw %}
• any of:
  • all of:
    • check-success="gcc-cuda / dbg"
    • check-success="gcc-cuda / opt"
    • check-success="gcc-cuda / sp"
  • check-skipped={% raw %}gcc-cuda / ${{ matrix.build_type }}{% endraw %}
• any of:
  • all of:
    • check-success="cpu-gcc / ERS_Ln22.ne4pg2_ne4pg2.F2010-SCREAMv1.scream-small_kernels--scream-output-preset-5"
    • check-success="cpu-gcc / ERS_Ln9.ne4_ne4.F2000-SCREAMv1-AQP1.scream-output-preset-2"
    • check-success="cpu-gcc / ERS_P16_Ln22.ne30pg2_ne30pg2.FIOP-SCREAMv1-DP.scream-dpxx-arm97"
    • check-success="cpu-gcc / SMS_D_Ln5.ne4pg2_oQU480.F2010-SCREAMv1-MPASSI.scream-mam4xx-all_mam4xx_procs"
  • check-skipped={% raw %}cpu-gcc / ${{ matrix.test.short_name }}{% endraw %}
• any of:
  • check-skipped=cpu-gcc
  • check-success=cpu-gcc

[bartgol]

Are these really all the same?

[AaronDonahue]

Yeah, I'm not sure. I'm pretty sure I only grabbed standard_names I was able to confirm either on the CF website or from EAM. Let me check again.

[AaronDonahue]

Good catch, I found better standard names with a little more digging.

[mahf708]

Unsolicited review: wouldn't we prefer to have this dict-type info in a yaml-like file somewhere in this folder (or elsewhere) instead of having it be part of the cpp code? I believe we could then just read the yaml file (or similar) to construct the map.

Of course, we can do that later, not necessarily in this PR ... I think it is tidier in the long run to have info like this stored in standalone files ...

[AaronDonahue]

Unsolicited review: wouldn't we prefer to have this dict-type info in a yaml-like file somewhere in this folder (or elsewhere) instead of having it be part of the cpp code? I believe we could then just read the yaml file (or similar) to construct the map.

Of course, we can do that later, not necessarily in this PR ... I think it is tidier in the long run to have info like this stored in standalone files ...

I like this idea. I could probably make that a part of this PR. @bartgol , do you have any thoughts on this approach?

[bartgol]

Looks good. Maybe we could change "long_name" to "description", since having a short, a long, and a standard name seem too much...

[bartgol]

Unsolicited review: wouldn't we prefer to have this dict-type info in a yaml-like file somewhere in this folder (or elsewhere) instead of having it be part of the cpp code? I believe we could then just read the yaml file (or similar) to construct the map.

Of course, we can do that later, not necessarily in this PR ... I think it is tidier in the long run to have info like this stored in standalone files ...

@jeff-cohere and I were working a while ago on a tool to enable this. You can see we have two databases in eamxx/data, containing yaml files for field names. We also developed string-matching tools in ekat, so that users can query the database to find what the real name is. We also thought about using it at runtime, but never had time to implement a robust approach. We can try in a following PR. Are you volunteering? ;-)

[mahf708]

Are you volunteering? ;-)

Yes! But only if I get to work with you and @jeff-cohere once we get to it (in a few weeks/months) ;)

The merge-base changed after approval.

[mahf708]

@bartgol uh oh... mergify merges without up-to-date approval, nice?!

[bartgol]

@bartgol uh oh... mergify merges without up-to-date approval, nice?!

I'm guessing that pushing new commits is not invalidating the check "#approved-reviews-by >= 1"? Seems odd that mergify looks for "any approval given during the lifetime of the PR", rather than checking that the last commit was approved...

[bartgol]

It appears that mergify does indeed that: so long as the PR was approved "at some point", that check passed. There's a mergify action that allows to dismiss reviews though. I want to see if we can use it to dismiss stale reviews. If not, then byebye mergify

[rljacob]

I think there's a github branch protection setting that might help: "Dismiss stale pull request approvals when new commits are pushed. New reviewable commits pushed to a matching branch will dismiss pull request review approvals."

[mahf708]

I think there's a github branch protection setting that might help: "Dismiss stale pull request approvals when new commits are pushed. New reviewable commits pushed to a matching branch will dismiss pull request review approvals."

I believe we have this already in this repo...