Should the Data Platform save nothing if one of many forecast creation attempts fail?

[devsjc]

In the UK model at least, each run of the forecaster results in the saving of nearly 400-odd forecasts, one for each GSP. In the current loop over the CreateForecast implementation, if one of these creations failed, only those values wouldn't be saved, and the remainder of the values for the other locations would be saved as normal.

However, @dfulu flagged that this might not be ideal behaviour in this case, due to something in the way the blend calculates things. He suggested it might be preferable to have a route that saves all of these forecasts at once (StreamCreateForecasts?), and so if one forecast creation fails, the whole lot fail.

@peterdudfield seems to be in two minds about it, and I don't know enough about the blend model to weigh in. Is this new route with that behaviour desired?

[dfulu]

I do think we should have a method that saves all forecast locations at once. In the UK all the GSP forecasts feed into the national forecast, and it seems messy if we might serve forecasts from each GSP that are based on different init-times.

Also for computing the blend, it makes our code much simpler to be able to assume that if an init-time is available, it is available for all GSPs. Otherwise we'd have to calculate blend weights for each GSP independently. We actually already made this assumption in the blend even if it isn't true right now. That assumption makes downstream code so much nicer, that I think it is worth making it true. I'd also guess that this wouldn't make our forecasts significantly more likely to crash. I don't think I've ever seen the logging to database function fail.

[peterdudfield]

Yea makes all sense. 

What do you think about the Shetlands failing, but everything else being OK. Shetlands doesn't really matter. 

Perhaps we start with all them saving, and one failing is ok. And if we need to harder that condition then we can

Bit please do what you both think is best

[dfulu]

Well for the shetlands specifically, we don't actually make predictions for it anymore since the GSP boundaries were updated. So we wouldn't be saving a forecast for that location

[devsjc]

Thanks both for weighing in (and for embracing my trial of using discussions, as opposed to issues, for this sort of thing!) It sounds like creating the route, but not as a high priority pre-deployment task, might be the way to go? Then it's usage is optional and we can try it out and see if it causes problems.

[peterdudfield]

Yea makes all sense. What do you think about the Shetlands failing, but everything else being OK. Shetlands doesn't really matter. Perhaps we start with all them saving, and one failing is ok. And if we need to harder that condition then we canOn 26 Sept 2025 17:21, James Fulton ***@***.***> wrote: I do think we should have a method that saves all forecast locations at once. In the UK all the GSP forecasts feed into the national forecast, and it seems messy if we might serve forecasts from each GSP that are based on different init-times. Also for computing the blend, it makes our code much simpler to be able to assume that if an init-time is available, it is available for all GSPs. Otherwise we'd have to calculate blend weights for each GSP independently. We actually already made this assumption in the blend even if it isn't true right now. That assumption makes downstream code so much nicer, that I think it is worth making it true. I'd also guess that this wouldn't make our forecasts significantly more likely to crash. I don't think I've ever seen the logging to database function fail. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>