-
Notifications
You must be signed in to change notification settings - Fork 4
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
Remove inconsistency regarding REMIND/EDGE-T communication of active modes energy service demand #24
Remove inconsistency regarding REMIND/EDGE-T communication of active modes energy service demand #24
Conversation
inst/remindoutputfiles.Rmd
Outdated
geom_line() + | ||
facet_wrap(~ all_regi, scales = axisScaling) + # Facet by region/country | ||
labs( | ||
title = paste("Capital cost for:", teEs), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be changed to "Final energy demand for: " - the wrong title confused me for a short moment :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for spotting :) I think I will also remove it from the package and store it in our helper script repo
setnames(ES, "value", "ES") | ||
f35_fe2es <- merge(ES, FE, by = intersect(names(FE), (names(ES)))) | ||
# Insert small number instead of zero | ||
f35_fe2es <- f35_fe2es[!ES < 1e-7] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@robertpietzcker The differences in the energy efficiency values for freight are coming from a change in how the energy efficiency is caluclated. They appear solely, where the energy service/final energy demand is anyway zero.
Previously I used the reciprocal energy intensity and aggregated it to all_teEs level by using the final energy demand as weight (energy efficiency is reported in (p|t)km/MJ to REMIND).
Where the whole branch has zero final energy demand, a weight of 1 was used, so that the energy intensity value does not disappear (the CES tree cannot deal with an energy efficiency of zero). Now I used FE and ES on te_Es level including the active modes to calculate the energy efficiency. To get rid of the zeros I used another method: I removed them beforehand and interpolated the missing values afterwards. Filtering out the zero demand values in advance ensures that we do not also interpolate NAs, which would indicate errors in the model if they occur.
So in summary: The changes come from a different way of dealing with zero demand values and don't affect the model results.
The REMIND CES tree cannot represent active modes, as they deliver valuable energy service demand without capital cost and final energy production.
Just filtering out the active modes energy service demand allocated by EDGE-Transport (as it was done so far) leads to inconsistencies between both models:
'E.g. REMIND would split the whole trn_pass energy service demand according to the FE shares and energy efficiencies reported by EDGE-T (without considering the active modes) and calculates a different FE value compared to EDGE-T that reserves a part of the trn_pass energy service demand to the active modes.
Solution: split and distribute the energy service demand of active modes across all technologies to calculate energy efficiency and capital cost per pkm.
Consequence: This leads to the fact that in REMIND energy service demand, energy efficiencies, an capital costs on technology level are rather abstract values that are not technically correct.
Hence, they should not be reported on technology level by REMIND (only by EDGE-T). The FE values on technology level are represented correctly as well as the energy service demand on CES node level.
The decision of the technology share is anyway made by EDGE-T and not by REMIND.
Comparison plots are here: /p/projects/edget/PRchangeLog/20240906_PR271_FixActiveModesInconsistency
This PR is related to PR#273 in edgeTransport