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

Remove inconsistency regarding REMIND/EDGE-T communication of active modes energy service demand #273

Merged
merged 6 commits into from
Sep 10, 2024

Conversation

johannah-pik
Copy link
Contributor

@johannah-pik johannah-pik commented Sep 6, 2024

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_PR273_FixActiveModesInconsistency
This PR is related to PR#24 in reporttransport

@robertpietzcker
Copy link
Contributor

Thanks a lot for removing this inconsistency that has been around for so long!

one question:
in the plots I see that in the early time steps, also some freight values seem to have changed:

image

Any idea where that came from, and is this potentially a problem?
Or does this only happen in time steps when the share of that route (eg esgat_freight_sm) is still 0, so that it anyway doesn't matter?

@johannah-pik johannah-pik merged commit ccf26e6 into pik-piam:master Sep 10, 2024
1 of 2 checks passed
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.

2 participants