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

add BCSD spatial disaggregation functionality #31

Open
dgergel opened this issue Jul 29, 2020 · 7 comments
Open

add BCSD spatial disaggregation functionality #31

dgergel opened this issue Jul 29, 2020 · 7 comments

Comments

@dgergel
Copy link
Contributor

dgergel commented Jul 29, 2020

@jhamman (and any others who might want to weigh in on this) I was wondering what your plan is for adding functionality for spatial disaggregation? Are you still thinking about something along the lines of bcsd_disaggregator as mentioned in the readthedocs? I have a prototype version of spatial disagg that I put together a few months ago that I could put into a PR in the next few weeks. Would be great to hear what you already have in mind for this piece so that I can make sure that my prototype would be along those lines.

@jhamman
Copy link
Member

jhamman commented Aug 4, 2020

@dgergel - Would you mind sharing your prototype concept? The BCSD disaggregator I was thinking of in the roadmap was a temporal disaggregator BUT I'm sure there are some interesting spatial methods to consider here as well. I think the criteria I'd put on accepting something like this fall as below:

  • uses a similar fit/predict api
  • accepts/returns xarray/pandas objects
  • doesn't add new (too many) dependencies

@dgergel
Copy link
Contributor Author

dgergel commented Aug 6, 2020

@jhamman a question from the criteria you listed: would xESMF fall under the category of adding too many dependencies, or would you be open to it being used?

The spatial disaggregator I have in mind would be implementing the NASA-NEX daily method, which applied bias correction at the native model resolution and then spatial disagg to move from the native model resolution to the finer obs resolution. The rough steps are:

  • subtract (divide for precip) BC’ed model data at model-res from obs climo at model resolution to calculate a “scaling factor”
  • bilinearly interpolate scaling factor from the model grid to the obs grid
  • apply scaling factor by adding (temp) or multiplying (precip) the scaling factor to the obs-res daily climatology

I've been thinking about how to adapt my prototype to use a similar fit/predict API. What I roughly have in mind is the fit step would be computing the scaling factor and bilinearly interpolating it, and then the predict step would be applying the scaling factor to the obs climo. Does that sound reasonable to you?

@jhamman
Copy link
Member

jhamman commented Aug 6, 2020

I'd like to avoid a dependency on xESMF (esmf really). For the workflow you've highlighted here, I think we can think of the a set of recipes that implement end-to-end downscaling patterns (like NASA-NEX). I don't think there is any problem adding xESMF to the doc build but I think we can stick to the principle that regridding is out of scope as built-in functionality in scikit-downscale. Ideally, all the regridding stuff can be made plug-and-play such that arbitrary workflows can be composed using a combination of tools (xarray/scikit-downscale/xesmf/etc.).

@dgergel
Copy link
Contributor Author

dgergel commented Aug 6, 2020

@jhamman fair enough. By adding xESMF to the doc build, do you mean a recipe for using xESMF as an intermediate step external to the workflow, or something beyond that?

Two options I'm thinking of that would accomplish this:

  • the option I think you're suggesting, where we compute a scaling factor in the fit step, use xESMF outside of the fit/predict API to interpolate the scaling factor, and include a "recipe" in the documentation for how to do this, and then apply the scaling factor as the predict step
  • alternative where the fit step would include one or more utility functions that draw on scipy to accomplish regridding solely for the scaling factor, but this wouldn't be built-in functionality that we use in other parts of scikit-downscale. I already coded this up in my prototype actually by taking out some xESMF source code.

@jhamman
Copy link
Member

jhamman commented Aug 10, 2020

@jhamman fair enough. By adding xESMF to the doc build, do you mean a recipe for using xESMF as an intermediate step external to the workflow, or something beyond that?

Yes. I'm just thinking a recipe (notebook or script of some kind) that we can include in the documentation showing how to use scikit-downscale with xesmf. (your options 1).

I'm having a bit of a hard time visualizing your second option. Can you provide an example (pseudocode or notebook if available)?

@dgergel
Copy link
Contributor Author

dgergel commented Aug 18, 2020

@jhamman what I had meant in my second option was that I was directly using source code from xesmf to apply regridding weights on dask workers, as I'd had trouble getting xesmf to work with dask distributed. Since then I've gotten it up and running, so I think a recipe in the docs would work well. I'm in the process of updating my prototype notebook and also adapting it to the fit/predict API so I'll share it once it's a bit more cleaned up.

@dgergel
Copy link
Contributor Author

dgergel commented Oct 20, 2020

Circling back on this - what I have in mind is a recipe like this:

  1. compute multi-decade daily climatologies of ERA-5 at obs-res and coarsen it to model-res ++
  2. subtract (or divide for precip) BC’ed model data at model-res from obs climo at model-res to fit a scaling factor **
  3. bilinearly interpolate “scaling factor” (using xESMF) from the model grid to the obs grid ++
  4. predict by adding or multiplying the scaling factor to the obs-res daily climatology **
  • ** steps that would take place within scikit-downscale
  • ++ steps that would be part of the recipe outside of scikit-downscale

The steps in scikit-downscale would call a SpatialDisaggregator class that has fit and predict methods. I have an initial implementation you can check out here.

Let me know your thoughts on this @jhamman - if this all sounds reasonable, I'll put together a PR.

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

2 participants