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

Is our "Fixer" class approach appropriate? #1

Closed
agstephens opened this issue Mar 11, 2020 · 3 comments
Closed

Is our "Fixer" class approach appropriate? #1

agstephens opened this issue Mar 11, 2020 · 3 comments
Assignees

Comments

@agstephens
Copy link
Collaborator

Please check whether the Fixer approach that we have implemented will be flexible enough to address all issues with CMIP5, CMIP6 and CORDEX data.

Use the ESMValTool repository to review examples of fixes that are needed.

Do we need something more than:

  • pre-processor
  • post-processor
@ellesmith88
Copy link
Collaborator

Currently can't see any issues that couldn't be fixed by either a pre-process or a post-process. However, CORDEX data isn't addressed in the ESMValTool so there are no examples of fixes for this as far as I'm aware.

@agstephens
Copy link
Collaborator Author

Let's close this and we can address issues as they arise.

@ellesmith88 ellesmith88 transferred this issue from roocs/proto-lib-34e Mar 30, 2020
@larsbuntemeyer
Copy link

Hey,
i just stumpled over this issue looking for CORDEX fixes. I collected some issues that i found working with the EURO-CORDEX ensemble here (euro-cordex/py-cordex#17) and implemented some fixes here (euro-cordex/py-cordex#35). I will try to have a look at your Fixer class approach, maybe i can contribute some fixes for CORDEX datasets.

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

No branches or pull requests

3 participants