test realtime data

[Tinkaa]

First test to understand the formatting of the seasonal forecast received in realtime from ECMWF.
Plust determine whether the trigger is met for February with the December forecast.

Would be great if you could have a second opinion whether the processing and the statistic results make sense.
Of course this needs to be incorporated in our pipeline but that requires quite some work.

[turnerm]

Looks good, but as we discussed it would be good to confirm with ECMWF what we are interpreting the time coordinates correctly

[turnerm]

Confirming that also here in the ECMWF API the time parameter corresponds to the forecast run date, which is the same as the first forecast date.

I'm wondering if we should move to setting time to be the baseline time, i.e. the time you add step to in order to get the forecast date. Otherwise step doesn't make much sense, unless you know that time is actually offset. What do you think?

[Tinkaa]

I'm wondering if we should move to setting time to be the baseline time, i.e. the time you add step to in order to get the forecast date.

Do you mean with baseline time it would be time - 1 month ?
I do think that it would make more sense to have time+step=forecast_date but instead of changing time I would change step . I.e. 0-index instead of 1-index step. I am not sure if we mean the same thing or not?

[Tinkaa]

but as we discussed it would be good to confirm with ECMWF what we are interpreting the time coordinates correctly

As we discussed bilaterally we found that the issue is with cfgrib which loads valid_time differently than what you would expect. This is explained in this GH issue.
I now changed the code to use forecastMonth and verifying_time instead of valid_time as explained in the linked issue.

[turnerm]

Do you mean with baseline time it would be time - 1 month ? I do think that it would make more sense to have time+step=forecast_date but instead of changing time I would change step . I.e. 0-index instead of 1-index step. I am not sure if we mean the same thing or not?

I would keep step the way it is, as it's supposed to represent the number of months in the future the forecast is for. So step=1 means the forecast is 1 month in advance, and I think using 0-indexing would just make this confusing.

This would mean setting the time parameter back one month. What do you think? But anyway it's not needed for this PR, perhaps for the pipeline though.

[Tinkaa]

This would mean setting the time parameter back one month.
I wouldn't do that though.. cause then it is confusing to me at least what time means and I haven't seen anyone else do it.. You would do it because then time represents the month the model was run?

[turnerm]

I wouldn't do that though.. cause then it is confusing to me at least what time means and I haven't seen anyone else do it.. You would do it because then time represents the month the model was run?

I guess my reasoning is that in order to know which month the forecast is referring to, you need to combine step with a baseline. Maybe instead of modifying time we could add something like baseline_time? Although now that I think about it we do have verifying_time so perhaps it's not needed.

[Tinkaa]

Yes maybe adding a verifying_time / baseline_time would be good. Lets continue the discussion in the pa-aa-toolbox issue and PR?

[Tinkaa]

All the processing and plotting has now been implemented in scripts. The processing is done in pa-aa-toolbox see this PR. The plotting and computing the trigger is done in #253
I would therefore propose to not merge this notebook to develop and thus close the PR. Would you agree?

[turnerm]

@Tinkaa yes good to close!