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

Include prognose in past plot #55

Open
ole-tange opened this issue May 24, 2021 · 2 comments
Open

Include prognose in past plot #55

ole-tange opened this issue May 24, 2021 · 2 comments

Comments

@ole-tange
Copy link

I would like to see how well Prognose matches Målt.

If you also plot Prognose for the past it should be easy to see how well these graphs match up.

(And is Biomasse really "vedvarende"? I get that it is CO2-neutral, but when you have burned down the last forest there is no more to burn).

@fuglede
Copy link
Collaborator

fuglede commented Jun 14, 2021

If you also plot Prognose for the past it should be easy to see how well these graphs match up.

One point of complication is that there's no single forecast for a given period: The forecasts are updated at fixed times, and the new forecasts will overlap with the old ones, so depending on what sort of questions you want to be able to answer, you may want different ones.

If you want(?) to be able to see how well the current forecast holds up, maybe the most recent one is useful. If you just want to see how well they're doing in general, you're probably better off getting the data from Energinet and performing the analysis out-of-band (could be interesting enough!) -- from my own usage, they generally seem to be doing fine; presumably, the step-like behavior you see in the forecast comes from known schedules for the combustion plants, which are known plenty of time in advance.

But the data is there so it'd just be a matter of not truncating the forecast in EmissionData.build.

(And is Biomasse really "vedvarende"? I get that it is CO2-neutral, but when you have burned down the last forest there is no more to burn).

Calling it renewable is certainly uncontroversial; chances are we won't run out of biomass any time soon. Note that biomass is more than just forests (in our part of the world, we like to burn a lot of straw, for example).

What's more controversial is calling it clean energy, or CO2 neutral: Sure, replacing the biomass with new stuff helps, but recapturing the CO2 you just emitted takes a long time, and we're CO2 positive in the remaining period; clearly it'd be strictly better to put down the new biomass, and not burn what you already had; you'll find plenty of studies suggesting that the marginal environmental impact is on par with fossil fuels.

For grønstrøm.nu in particular, this has the annoying consequence that in our CO2 emission intensity calculations, biomass enters with a coefficient of 0 g CO2e/kWh (due to a political decision to include the environmental impact of biomass before Energinet adds their contributions to the budget); I'd much rather (#49) be able to include it explicitly, e.g. using coefficients a la the IPCC estimate of 230 g CO2e/kWh, but the data doesn't quite make that possible (yet, but I get the impression that they're toying with the idea of splitting the forecasts into production type, which is what we need).

@fuglede
Copy link
Collaborator

fuglede commented Jun 20, 2021

So, while it's straightforward enough to add the "historical" forecast, I'm not sure if the provided data is much use by itself: The forecast is updated at a relatively high frequency, so just using the most recent forecast, the fit will always be good:

image

We could in principle just store the forecast at some pre-defined period of time -- i.e. store the forecast as it looked like a day ago -- but that would require constantly fetching forecasts, storing those somehow (breaking the otherwise stateless nature of the app), and deciding on some arbitrary period (i.e. do we want the 6-hour delayed forecasts or the 24-hour delayed forecasts, and why prefer one over the other). I'll call "there's no good/natural way of doing this, so this is better suited for an out-of-band analysis such as fetching a whole bunch of forecasts over an extended period of time, then quantify how good forecasts are for any forecast horizon".

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