Skip to content

Add support for tminavg and tmaxavg#35

Merged
znicholls merged 5 commits intomainfrom
update-temporal-labels
Sep 24, 2025
Merged

Add support for tminavg and tmaxavg#35
znicholls merged 5 commits intomainfrom
update-temporal-labels

Conversation

@znicholls
Copy link
Copy Markdown
Owner

@znicholls znicholls commented Sep 22, 2025

Description

Checklist

Please confirm that this pull request has done the following:

  • Tests added
  • Documentation added (where applicable)
  • Changelog item added to changelog/

@codecov
Copy link
Copy Markdown

codecov Bot commented Sep 22, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.50%. Comparing base (129009e) to head (1048e34).
⚠️ Report is 30 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #35      +/-   ##
==========================================
+ Coverage   98.46%   98.50%   +0.04%     
==========================================
  Files           7        7              
  Lines          65       67       +2     
  Branches        8        8              
==========================================
+ Hits           64       66       +2     
  Partials        1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@znicholls
Copy link
Copy Markdown
Owner Author

@taylor13 @JamesAnstey thoughts welcome

@JamesAnstey
Copy link
Copy Markdown
Contributor

Thanks @znicholls for implementing this, looks good to me.

A quibble: since the cell methods for these variables has "time: minimum within days time: mean over days" (or similar for max) would keying off just the cell methods be more general, rather than using time4? In case in future the same cell methods is used for a time averaging period that's not a month (as time4 is specified for in the DR). But for the AFT DR it doesn't matter since there are only 5 affected variables and all are monthly with time4 as their time dimension.

@znichollscr
Copy link
Copy Markdown
Contributor

A quibble: since the cell methods for these variables has "time: minimum within days time: mean over days" (or similar for max) would keying off just the cell methods be more general, rather than using time4?

Yes probably. At the moment I'm just blindly implementing Table F1 from whatever version of Karl's draft I last looked at, but I'm sure Karl would be happy to talk about the logic of the underlying algorithm too (which can then appear here, with fun thoughts like how careful we need to be about the ordering of the operations in the cell methods and how to match them robustly). Timing of all that up to you too

@taylor13
Copy link
Copy Markdown

To add my 2 cents ... currently and I think in the future CMIP phases, "time4" will invariably imply that the cell methods includes either "time: minimum within days time: mean over days" or "time: maximum within days time: mean over days" (or similar for max)", so I think the current test will remain robust. The "time_label" should not care about the reporting frequency, so the same method will apply for a mean over a year or a decade or a week. All those will have "time4" as a dimension (just as "time1" indicates point sampling, independent of frequency).

@JamesAnstey
Copy link
Copy Markdown
Contributor

Ok gotcha, thanks @znicholls & @taylor13. So it sounds like in future the VR definition of time4 would be updated to not refer specifically to a monthly mean, to accommodate other possible averaging periods. But for the current DR it's perfectly fine.

@znicholls
Copy link
Copy Markdown
Owner Author

Ok I think we're all good then. @eahoegner @NiklasSchwind @TessaM97 FYI more updates. I'll merge and release now

@znicholls znicholls merged commit 6b1fdca into main Sep 24, 2025
21 checks passed
@znicholls znicholls deleted the update-temporal-labels branch September 24, 2025 20:55
@taylor13
Copy link
Copy Markdown

@JamesAnstey I mean it couldn't hurt to update the description of time4 in the data request to be consistent with Table F1, which does not restrict it to a single frequency, but it's not essential, I guess.

@znicholls
Copy link
Copy Markdown
Owner Author

@JamesAnstey I mean it couldn't hurt to update the description of time4 in the data request to be consistent with Table F1, which does not restrict it to a single frequency, but it's not essential, I guess.

+1. For context, I think most (all?) the values in the VR at the moment are just placeholders. Cleaning up all these definitional things would be something for when we go full steam on the VR

@znicholls
Copy link
Copy Markdown
Owner Author

Released now https://pypi.org/project/cmip-branded-variable-mapper/0.11.0/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants