-
Notifications
You must be signed in to change notification settings - Fork 130
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
add support for switch to force monotonously decreasing solids fossil use per region #1873
add support for switch to force monotonously decreasing solids fossil use per region #1873
Conversation
*' Limit solids fossil to be lower or equal to previous year values | ||
***--------------------------------------------------------------------------- | ||
$ifthen.limitSolidsFossilRegi not %cm_limitSolidsFossilRegi% == "off" | ||
q_fossilSolidsLimitReg(ttot,regi,entySe,entyFe,sector,emiMkt)$(limitSolidsFossilRegi(regi) and (ttot.val ge max(2020, cm_startyear)) AND sefe(entySe,entyFe) AND sector2emiMkt(sector,emiMkt) AND (sameas(sector,"indst") OR sameas(sector,"build")) AND sameas(entySe,"sesofos")).. |
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 is on for ttot = 2020, so that in 2020 fossil solids use already has to go down.
I guess we are positive that the average of 2018-2022 is already lower than the average 2013-2017 in each EU region and US historically?
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.
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.
If you are ok with it, I would merge as is for now as I only enable this for EU27 in my paper runs, and I will check on enforcing historical values after I submit the paper revision.
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.
sure, merge for now.
just wondering: what would speak against setting the starting point to 2025? I don't think the runs ever produced a solids spike in 2020, only in 2025?
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.
I ran a test where I enforced this change only from 2025 onward, and part of the spike shifted to 2020.
I need to test this again, but for now, I would keep it as is.
In the near future, I plan to implement both the enforcement of historical values up to 2020 and adjust the start year for this switch to 2025.
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.
looks good
Purpose of this PR
Type of change
Checklist:
FAIL 0
in the output ofmake test
)Further information (optional):
/p/projects/ecemf/REMIND/2040_scenarios/_mergeTest/remind_seFeSectorSharePenalization_2025/output