Give lev_bnds its own formula_terms from z_bounds_factors (CF §4.3.3) - #641
Merged
Conversation
A parametric vertical coordinate's bounds variable needs its own
formula_terms, referencing the bounds of each term. For hybrid-height
variables (cl, cli, clw) lev_bnds carried none, failing the CF-1.11 check:
§4.3.2: lev_bnds's formula_terms is a required attribute
and must be a non-empty string
lev itself gets formula_terms by inheritance from the UM source coordinate
(theta_level_height), retargeted to the post-rename names. Its bounds
variable has no attributes in the source, and the CF §7.1 loop in
update_attributes() replaces bounds attrs wholesale from an INHERIT_KEYS
subset that never included formula_terms.
The correct value was already in the coordinate table as z_bounds_factors
("a: lev_bnds b: b_bnds orog: orog"), until now read only to decide which
bounds variables to create. Apply it after the §7.1 loop, which would
otherwise wipe it. Adding formula_terms to INHERIT_KEYS would instead copy
the parent's "a: lev b: b orog: orog", which points at the coordinates
rather than their bounds and is equally non-compliant.
Skipped when z_bounds_factors is empty (hybrid_height_half) or when any
referenced variable is absent, so no dangling reference is written.
Verified end to end on cl: §4.3 Vertical Coordinate goes from [5, 6] with
the message above to [10, 10] clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #641 +/- ##
=====================================
Coverage 77.2% 77.2%
=====================================
Files 40 40
Lines 8514 8522 +8
Branches 1590 1593 +3
=====================================
+ Hits 6575 6583 +8
Misses 1610 1610
Partials 329 329
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Member
|
Fixes #642 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A parametric vertical coordinate's bounds variable needs its own formula_terms, referencing the bounds of each term. For hybrid-height variables (cl, cli, clw) lev_bnds carried none, failing the CF-1.11 check:
lev itself gets formula_terms by inheritance from the UM source coordinate (theta_level_height), retargeted to the post-rename names. Its bounds variable has no attributes in the source, and the CF §7.1 loop in update_attributes() replaces bounds attrs wholesale from an INHERIT_KEYS subset that never included formula_terms.
The correct value was already in the coordinate table as z_bounds_factors ("a: lev_bnds b: b_bnds orog: orog"), until now read only to decide which bounds variables to create. Apply it after the §7.1 loop, which would otherwise wipe it. Adding formula_terms to INHERIT_KEYS would instead copy the parent's "a: lev b: b orog: orog", which points at the coordinates rather than their bounds and is equally non-compliant.
Skipped when z_bounds_factors is empty (hybrid_height_half) or when any referenced variable is absent, so no dangling reference is written.
Verified end to end on cl: §4.3 Vertical Coordinate goes from [5, 6] with the message above to [10, 10] clean.