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

replace stationary by ONONSPEC projection #644

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

robinhasse
Copy link
Contributor

@robinhasse robinhasse commented Mar 6, 2025

This PR introduces a new projection of non-specified IEA balance flows that are currently mapped to buildings. A different allocation across sectors proposed in #609 is not subject of this PR.

status quo

There is a very old file that has SSP1 - SSP5 scenarios for all demand mapped to industry and buildings. All energy demand that is mapped to buildings but not represented in EDGE-B currently comes from this file as "stationary". In convertStationary, the outdated historic demand from the file is replaced by current IEA balance data that linearly transitions to the projections in the file when going into the future. The respective flows belong to the IEA flow ONONSPEC - other non-specified demand. Even though we have no idea what this is, there are different projections either approaching zero or higher values. In the most striking example, we see exponentially increasing historic electricity demand in CHN but a decay towards zero in the projections.

change

This PR gets rid of the file overall. Instead we now project the IEA demand dynamically based on the most recent historic observations. As we have no idea, where the demand comes from, I want to avoid to make too specific assumptions for the future, so we just continue with the recent slope and then approach a constant value.

method

We assume an asymptotic model. It start from the level $x_0$ at the end of history (EOH) and with the EOH slope $\dot{x}_0$ and approaches the fraction $\epsilon$ of this slope within $\Delta t$. Both $x_0$ and $\dot{x}_0$ are determined through a linear regression of the last $n$ time steps.

$x(t) = x_0 + \dfrac{\dot{x}_0}{c} \cdot [ 1 - \exp ( - c \cdot ( t - t_0 ) ) ]$
with the decay rate $c = -\dfrac{\ln \epsilon}{\Delta t}$

The method requires the following parameters. I indicated my current choice

  • $n = 5$: not as relevant, I think.
  • $\epsilon = 0.05$: tolerance to considere the slope constant. The higher this parameter, the higher (lower) are approached long-term values for positive (negative) EOH slope.
  • $\Delta t = 15 - 25 yr$: time span within which slope has decreased to a value considered constant: $\dot{x}(t_0 + \Delta t) = \epsilon \cdot \dot{x}_0$

scenarios

I had a hard time thinking of a scenario differentiation for the projections as we had them with stationary before. @robertpietzcker, do you think this is necessary? As a first example, I created a low, med and high scenario referring to the long-term projection level by differentiating $\Delta t$. We can adjust the parameterisation and would have to map the level scenarios to SSPs.

scenario $\Delta t$, if $\dot{x}_0 > 0$ $\Delta t$, if $\dot{x}_0 \le 0$
low 15yr 25yr
med 20yr 20yr
high 25yr 15yr

This is a comparison of the projections showing the new scenarios as thick lines and the old ones in thin lines. Mind that the old scenarios are without my hot fix in #635.
ononspecComparison

implementation

This one is for @fbenke-pik: I currently get the relevant IEA flows through calcOutput("IOEdgeBuildings", subtype = "output_EDGE"). This gives me the stationary IEA flows in buildings. From these, I still filter only those flows that are not represented in EDGE-B. This works fine but seems a bit intransparent. It might be better to update the mapping structuremappingIO_outputs.csv to get just the flows we need here and not the ones represented in EDGE-B. Not sure if this would come with an overall change to mrcommons:calcIOEdgeBuildings and what cache implications would be.

@robinhasse robinhasse marked this pull request as draft March 6, 2025 14:35
Copy link
Contributor

@ricardarosemann ricardarosemann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, the implementation looks good and makes sense and I find most of the resulting projections reasonable (with few exceptions). Let me know if you want me to look at some more details.

periodEOH <- max(x$period)
coefs <- data.frame(periodEOH = periodEOH,
slopeEOH = coef(m)[["period"]],
valueEOH = predict(m, list(period = periodEOH)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
valueEOH = predict(m, list(period = periodEOH)))
valueEOH = predict(m, data.frame(period = periodEOH)))

Not sure if this makes much of a difference, but usually predict takes data frames.

@robinhasse
Copy link
Contributor Author

robinhasse commented Mar 6, 2025

This is for $n=10$. Not radically different but outliers like in REF feothliquid distort less.
ononspecComparison_n10

@robertpietzcker
Copy link
Contributor

yes, the second version looks better, especially when looking at REF :-)
I like it

@robinhasse
Copy link
Contributor Author

robinhasse commented Mar 6, 2025

Thanks @robertpietzcker. If you could quickly answer these questions (or approve my suggestions). Thanks!

  • Do you think, it is worth keeping a scenario differentiation in the projections?
  • Do the 3 scenarios differentiated by long-term level make sense to you and are you happy with the parameterisation?
  • How would you map the level scenarios to the SSPs? This would roughly fit total FE demand in EDGE-B scenarios:
SSP scenario level scenario
SSP1 low
SSP2 med
SSP3 med
SSP4 med
SSP5 high

@robertpietzcker
Copy link
Contributor

robertpietzcker commented Mar 6, 2025

yes, looks good to me.
you could also map "high" to SSP3, as Nico is designing it to lead to high demands if I understood correctly
as you like

Copy link
Contributor

@robertpietzcker robertpietzcker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't comment on the R code, but the results look good

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

Successfully merging this pull request may close these issues.

3 participants