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 a seasonal locality option #47

Open
gutmann opened this issue Feb 2, 2017 · 1 comment
Open

Add a seasonal locality option #47

gutmann opened this issue Feb 2, 2017 · 1 comment

Comments

@gutmann
Copy link
Member

gutmann commented Feb 2, 2017

Many downscaling methods operate independently for each month of the year to help preserve the seasonal cycle.

This can be done in GARD by downscaling separately for each month, but this requires substantial pre-processing of input data (separating monthly data for independent GARD runs and stitching back together in the end)

It is relatively simple to add a “day of the year” variable to the input files, and use that (in any of the analog schemes anyway). To be able to wrap around the year it could be two variables (equivalent to “u” and “v” for wind direction with a unit length). That way days that are far away (in day of year) would have to be very similar for all other variables, while days that are close in day of year would be given more flexibility. It is a little awkward, but might help… It probably will not help the pure regression mode though.

Alternatively it would be nice to add a Day-Of-Year localization option in GARD.

For the pure regression mode this would be tricky, and require GARD to either call downscale_point ~12 (or whatever) times after subsetting the data appropriately each time, then stitching it back internally.

For the analog MODES, it should be possible for GARD to simply have an option (in select_analogs) to take time data and enforce that DoY be within X-days for any analogs selected. This part would be "easy"

@gutmann
Copy link
Member Author

gutmann commented Feb 2, 2017

locality option should be able to specify how many days on either side of the current day should be included (at least for analog options, that gets really difficult with pure_regression)

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

1 participant