Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monthly ESMValTool meeting July #2189

Closed
bouweandela opened this issue Jun 7, 2021 · 9 comments
Closed

Monthly ESMValTool meeting July #2189

bouweandela opened this issue Jun 7, 2021 · 9 comments

Comments

@bouweandela
Copy link
Member

bouweandela commented Jun 7, 2021

The next monthly ESMValTool meeting will be in July. The result of the poll is that it will be on

Thursday, July 1 at 14:00 CEST (13:00 BST).

The duration will be one hour. Join the zoom meeting.

Calendar invitations to the meeting are sent to the mailing list, join it here.

@ESMValGroup/esmvaltool-developmentteam

Format and agenda

  • Anyone with an interest in ESMValTool is welcome to join and ask questions
  • We start the meeting by doing a round where everyone gets one minute to introduce themselves and tell what they will be working on in the next month or what they would like help with.
  • Using the input from the introduction round, we can decide to talk about specific topics with the entire group or make smaller breakout groups to continue the discussion there.
  • If you already know that you would like to bring up a particular topic in the meeting, you can mention the GitHub issue on the topic in a comment in this issue. That will make it easy to find for other people in the meeting and we can already start discussing there before the meeting. Just create a new GitHub issue about your topic if there is no open issue yet.
  • GitHub issues are our preferred way to communicate outside the meeting and keep track of work, so any feature requests/action items/etc discussed in the meeting should ideally result in a GitHub issue.

Notes from the June meeting can be found here: #2173 (comment)

@bouweandela bouweandela pinned this issue Jun 7, 2021
@remi-kazeroni
Copy link
Contributor

It would be good to have a discussion about cases like #1812:

  • If merged now, Update WOA cmorizer for WOA18 and WOA13v2 #1812 the old cmorizer script (i.e. WOA13) would be erased and replaced by the latest one (WOA18) which differs from the previous one. Do we rather want to keep one cmorizer script per dataset version? Or do we only want to have a cmorizer for the latest version of the obs data?
  • Also the recipe recipe_ocean_bgc.yml relies on WOA13. Unless this recipe is modified to use the latest dataset version, merging Update WOA cmorizer for WOA18 and WOA13v2 #1812 means that we don't have the cmorizer for the obs data of that recipe.
    See also this comment on the topic.

@bouweandela
Copy link
Member Author

I think it might be best to keep all versions of the CMORizers, because

  • even if we update the recipes in the ESMValTool repository, we're not sure if someone is keeping more recipes somewhere else
  • this would be useful for reproducing or comparing results with different versions of the same dataset

Only when the data for an older version is no longer available anywhere it makes sense to delete the cmorizer script.

@remi-kazeroni
Copy link
Contributor

I think it might be best to keep all versions of the CMORizers, because

* even if we update the recipes in the ESMValTool repository, we're not sure if someone is keeping more recipes somewhere else

* this would be useful for reproducing or comparing results with different versions of the same dataset

Only when the data for an older version is no longer available anywhere it makes sense to delete the cmorizer script.

Fully agreed. Another question is whether we keep one config file and one script per dataset version or if we try to have everything in one config file and one script. See this comment for another cmorizer update.

@valeriupredoi
Copy link
Contributor

I'd like to bring forth two topics of discussion:

@rswamina
Copy link
Contributor

rswamina commented Jul 1, 2021

I'd like to give an update from the recently held User Engagement Team meeting.

@bouweandela
Copy link
Member Author

bouweandela commented Jul 1, 2021

Thank you for attending everyone! Here is a summary of the topics we discussed in the meeting:

User engagement update by @rswamina

  • 2 new members @ehogan and @SarahAlidoost
  • the team will make introductory talks to ESMValTool available on www.esmvaltool.org, please share any ESMValTool related talks with @ESMValGroup/userengagementteam
  • Slides are available for re-use if you would like to introduce ESMValTool to a new audience, get in touch with the @ESMValGroup/userengagementteam to request access
  • There are plans to improve tutorial over the coming months, based on user feedback
  • 2 new projects are using ESMValTool: LaunchPad (climate diagnostics for Africa) and Acclimate (climate diagnostics for Brazil)
  • The next user engagement team meeting will be held in September

Different versions of CMORizer scripts

  • we discussed the topic and agreed to keep at least older versions of CMORizer scripts. We need to write some contribution guidelines explaining that old versions should not be replaced, but a new version should be added. It is important that reviewers check this. @remi-kazeroni Would you be willing to write the guidance?

Multimodel statistics

  • The multimodel statistics preprocessor uses iris instead of numpy since Use native iris functions in multi-model statistics ESMValCore#1150 was merged and this is included in ESMValCore v2.3.
  • Because of the more strict handling of metadata by iris, some recipes do no longer run with ESMValCore v2.3. In some cases, the more strict checks on metadata may indicate a true scientific problem, while in other cases this may be too pedantic.
  • Because we aim to release ESMValTool with all recipes working, a patch release of ESMValCore v2.3 seems likely.
  • Several options have been proposed to solve the issue of recipes not working that should actually work in ESMValCore v2.3.1:
    • Keeping the new implementation and addressing the any problems with preprocessor functions that come before multimodel statistics
    • Keeping both multimodel statistics preprocessor
    • Reverting back to the old multimodel statistics preprocessor
  • @zklaus Will make an overview discussion, linking to individual issues that describe cases where recipes fail. If you have an opinion on this topic or a problem to report, please go to this discussion.
  • Several people reported that they found it difficult that they only found out about changes in the ESMValCore when a release is made and then have very little time to adjust. Maybe it would help to publish a release candidate on conda, to avoid having to do a patch release immediately after ESMValCore is released. For previous releases of ESMValCore we asked the @ESMValGroup/esmvaltool-developmentteam to test the ESMValCore after the feature freeze, but in this case that did not happen. Some streamlining and better documentation of the release process might be needed.

Python 3.6 support

  • Python 3.6 is end of life in September, so ESMValCore v2.3 will be the last release that supports it.

@SarahAlidoost
Copy link
Contributor

Here I am tagged as a new member :bowtie: but "Tamzin Palmer" is one of the new members of the user engagement team.

@bouweandela
Copy link
Member Author

Sorry, I must have been sleeping when I was taking the notes 💤 💤 💤

@zklaus
Copy link

zklaus commented Jul 2, 2021

The discussion about multi-model issues is now available at #2218, though a few issues are still missing.

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

No branches or pull requests

6 participants