Cmorize hadcrut5

[mwjury]

• ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the PR is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• 🛠 PR has a descriptive title for the changelog
• 🛠 Code follows the style guide
• 🛠 Circle/CI tests pass
• 🛠 Codacy code quality checks pass

New or updated data reformatting script:

• 🛠 Dataset is added to the table in the documentation
• 🛠 Documentation contains instructions to obtain the data
• 🛠 Tests for the CMORized data are available
• 🧪 Numbers/units of the data look physically meaningful
• 🛠 Data set is added to the OBS data pool @remi-kazeroni

I added a cmorizer for the new HadCRUT5 dataset.

Any suggestion on the protected function issues?

[valeriupredoi]

documentation tests failed because numpy was offline and the test tests fail coz of this #1980 - I'll have a look at the code later but don't worry about the tests!

[valeriupredoi]

cheers @mwjury - a small remark about using the utils module; I will merge once we merge the fix to the iris documentation from #2012 🍺 Also, question about all your cmorizers that you have written so far - and great many thanks, awesome contributions - did you produce the cmorized data and alerted @remi-kazeroni of the new data to be uploaded on DKRZ (I imagine not JASMIN since I've not heard of any new data coming there). It's good to get in this habit, since this saves the future user the chore of cmorizing it themselves 👍

[valeriupredoi]

just use utils.fix_coords(cube) for this

[mwjury]

The problem with fix_coords is that it calls _fix_bounds on the time coordinate -> removing and reguessing bounds and thereby screwing up the monthly bounds via its linear interpolation ...

[valeriupredoi]

aha good pointer! I'll put in a patch to utilities.fix_coords() via an optional argument to keep the bounds untouched 👍

[valeriupredoi]

note that now we have a a set of new args to this function that allow the developer to turn off overwriting the bounds, so next time it's best to use that. It's fine here, no need to change the code 👍

[mwjury]

@valeriupredoi utils.fix_coords(cube) not gonna work unfortunately.
I have added @remi-kazeroni to the todo list when I opened the pull request. Not sure what else to do in this regard. I am using ESMValTool currently neither on DKRZ nor CEDA, but on my institute's infrastructure.

[remi-kazeroni]

I have added @remi-kazeroni to the todo list when I opened the pull request. Not sure what else to do in this regard. I am using ESMValTool currently neither on DKRZ nor CEDA, but on my institute's infrastructure.

I suggest that I could do a final review this PR and test the cmorizer at DKRZ: data download and cmorizer. If things are fine I'll approve and put the data in the right directories on DKRZ. I'll do that for all your cmorizer PRs ready to merge before the code freeze. Is that fine @mwjury @valeriupredoi ?

[valeriupredoi]

totally awesome, cheers @remi-kazeroni for that and @mwjury for the code!

[remi-kazeroni]

Nice work @mwjury ! The cmorizer and the check_obs recipe work fine for me. It uploaded the cmorized data on Mistral.

The only thing is that a later version of the data is now available instead of what you documented. Could you please change from 5.0.0.0 to 5.0.1.0 (or use wildcards: 5.*.*.*) in the documentation and the config file? And replace 2018 by 2020 in the recipe_check_obs.yml? And perhaps merge the master branch to resolve the failing tests? Thanks!

[bouweandela]

Just applying some new labels to make the status of all open pull requests more clear. Note that the tests on CircleCI and the documentation build must be successful (green) before the label 'approved by technical reviewer' can be applied.