adapt for sub-annual predictions about climpred HOT 10 CLOSED

now the tests run though for monthly datetime inputs.

however, for PPP, NMSE, NRMSE, NMAE, I should normalize according to the specific std of that month as in Bushuk (2018).

I didnt look into the results yet, but for pearson_r, rmse, mae, mse it should be fine.

from climpred.

Any reason why you dont take the meteorological 'DJF',... seasons?

I'm looking at the California Current where upwelling seasonality can be distinctly binned into JFM, AMJ, JAS, OND. That's the only reason why.

Question about annual forecasts: do you consider lead year 1 from Jan-Dec or Nov-Oct?

Lead year 1 for us is Jan-Dec following the initialization. So, initialization of November 1955 has a lead year 1 of Jan-Dec of 1956.

I think its a good implementation to implement for monthly and seasonal forecasts. Maybe you can even separate all the seasonal and monthly preadjustments into one function, so the skill function as such works as in all the other cases.

Yeah I think this is a starting point. We should implement it well, though, and it might take some work. I think we should focus on getting classes working for annual resolution and other features, then scale it to higher temporal resolution.

from climpred.

Issue started nearly one year ago. A big one.

from climpred.

@aaronspring, good point. I can check on this in the coming weeks as I'll start looking at monthly output from CESM-DPLE soon.

persistence forecast to incorporate climatology

I think this should be okay, since the user should be submitting anomalies anyway. For most of these functions, the expectation would be that the user does something like this:

# let's say I already loaded in monthly DPLE
dple_dt = xr_remove_trend(dple)
dple_ds = dple_dt.groupby('time.month') - dple_dt.groupby('time.month').mean('ensemble')
# input dple_ds into a compute function

I just wrote this from the top of my head here so don't look too closely. Point is, it should just be treated as anomalies (from mean, trend, and climatology) with the same dimension names.

from climpred.

Based on the testing my bootstrapping function cannot handle mm output.

from climpred.

@aaronspring , I see this problem now. I didn't think about this too hard before. I'm now working with seasonal data.

The annual was fine with single initializations since we could just directly correlate the annual time series. But here for monthly/seasonal, we need to stride through them to compare the same month to the same month or season.

I'm writing a clunky solution in my Jupyter notebook for this project for now. But this is something that will be helpful to solve with classes (once we merge your bootstrap + my initial classes). The object could have a label about its time resolution (annual, monthly, seasonal) and routes through a different approach depending on that.

Persistence I imagine is fine...

from climpred.

I think this is going to be a hard thing to generalize. Or maybe not. Here's my solution for my project, using seasonal forecasting.

Some technical info to explain the code:

• Initialization in DPLE occurs on Nov. 1 of each year.
• I am using seasons 'JFM', 'AMJ', 'JAS', 'OND'
• Thus, the first lag is 'ND' of the same initialization year
• lags 2-5 are then the four seasons of the following year
• The FOSI reconstruction ends at 2017-12

nseasons = 4
plag = []
for nlag in range(DPLE.time.size):
    a = DPLE.isel(time=nlag) # zoom in on the lag we're on
    b = FOSI[nlag::nseasons] # just select the season of interest. OND, JFM, AMJ, JAS...
    deficit = len(b) - len(a)
    if deficit != 0:
        a = a[:deficit]
    b['initialization'] = a['initialization']
    plag.append(pearson_r(a, b, dim='initialization'))
skill = xr.concat(plag, 'time')

FOSI is sliced from 1954-11 to 2017-12. The DPLE is initialized every year from 1954 to 2017. So after I select with a = DPLE.isel(time=nlag) and b = FOSI[nlag::nseasons], we are down to annual resolution again. Comparing the same seasons of every year. Since they started out spanning the same time frame, I can just check the difference in length of them and trim that off the end.

from climpred.

I understand how this snippet trims down the code to match the sizes. makes sense. and before you carve out you the seasonal. so the input data needs to contain timesteps 'JFM1', 'AMJ1', 'JAS1', 'OND1','JFM2', 'AMJ2', 'JAS2', 'OND2'
Any reason why you dont take the meteorological 'DJF',... seasons? The code should be adaptable.
So for your project you basically omit the first month of your first season.
Question about annual forecasts: do you consider lead year 1 from Jan-Dec or Nov-Oct?

I think its a good implementation to implement for monthly and seasonal forecasts. Maybe you can even separate all the seasonal and monthly preadjustments into one function, so the skill function as such works as in all the other cases.

from climpred.

Also note that compute_persistence breaks for less-than-annual resolution in its current state (this will be caught in the future with good testing).

    for lag in range(1, 1 + nlags):
        inits = ds['init'].values
        ctrl_inits = reference.isel({dim: slice(0, -lag)})[dim].values
        inits = _intersection(inits, ctrl_inits)
        ref = reference.sel({dim: inits + lag})
        fct = reference.sel({dim: inits})
        ref[dim] = fct[dim]
plag.append(metric(ref, fct, dim=dim))

Due to the above code. ctrl_inits will be monthly datetime, inits will be integers of initialization years (for CESM at least). There is no intersection then since they're different units.

from climpred.

Discussion and work done here: https://github.com/bradyrx/climpred/pull/172

from climpred.