-
Notifications
You must be signed in to change notification settings - Fork 129
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
make waste incineration emissions part of chemicals MAC curve #1662
Conversation
… of unaccounted CCS
Test runs have only been started just now; implementation might still have bugs. And we should definitely adjust MAC curve parameters to account for different costs & capture rates in waste incineration. |
v37_plasticWaste(t,regi,entySe,entyFe,emiMkt) | ||
* pm_incinerationRate(t,regi) | ||
) * (1 - p37_regionalWasteIncinerationCCSshare(t,regi)) |
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 currently don't understand this - won't this mean that vm_incinerationEmi will always show the FULL carbon content burned, even if part of that is captured?
if yes, it would be good to adjust the description of vm_incinerationEmi to highlight this.
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.
Yes you are absolutely right. And more importantly, we have to update remind2.
We could do this with a postsolve parameter which applies the same capture rate on this as on the rest of the chemicals subsector, but I'd have to also check the implications of the now increased vm_emiIndCCS
.
This will take a while, an I'm on holidays next week.
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.
Looking forward to Ctrl+F
through 3000 lines of reportEmi...
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.
Its just four lines with vm_incinerationEmi
, quit the whining.
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.
You do it then :)
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.
Hi Jakob, what is the status of the runs to check the implementations? |
Runs converged. I haven't checked the results yet. But in order to get meaningful and easy to interpret results, we need to adapt remind2. |
…_incineration_mac separate incineration emi before and after CCS to ease reporting
7e0e8bd
to
41c9ad5
Compare
if some comment/ review from me is needed, please ping me - the way I interpret it this is still under work, right? |
Current state:
|
Back to the drawing board. |
I faintly remember someone saying
and someone else replying to
😇 |
…iteration, such that CONOPT sees the incentive to reduce ue_cement
… to work for fixed_shares
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 am not convinced anymore that this is a desirable solution.
For one thing, it mixes two hitherto separate categories of energy and emissions in the chemicals subsector, FE use and non-FE use, in a way that makes it almost impossible to disentangle afterwards.
For another, what is the justification for applying the MAC curve for chemicals CCS to waste incineration?
Hm. |
It was always a trade-off between implementation time and outcome. |
so the question is "what are the requirements until maybe September/October, when we can hope for an updated implementation?" for the projects I am involved with, we need to have stringent mitigation scenarios where there is no large amount of fossil waste emissions remaining in 2050, but we don't need a lot of subsectoral detail. I think this "putting waste emissions into industry chemicals MAC" approach was an idea to achieve this aim. However, if there is a project that requires information on sub-industry-sector level, this approach will clearly not be sufficient. Now the question is: Is there any such project with runs needed in the next 5 months? if not, I would still propose to go for "use the chemicals MAC" as a short-term solution, knowing full well that this needs to be cleaned up by the person coming in July. If there are other ideas about rather easy solutions for getting rid of the sizable fossil waste incineration emissions in 2050 NetZero scenarios, I am also open for it. |
|
Putting waste CCS into the same bucket as chemicals CCS, when the FE streams are in different buckets, disqualifies this solution for every project in which somebody might take even a cursory glance at industry results, in my view.
We usually guestimate that people need six months to get up to speed with REMIND. We never guestimated how long it takes to get up to speed with |
which is exactly why I asked if you know of any project that needs this. but your proposal anyway sounds better, if it is relatively easy to implement. (it sounds quite easy to simply copy the code and change the name, but as I never really worked with the MACs I can't really comment on that) I think the second step shouldn't be challenging - we can ask Jess' group for a rough estimation of waste CCS costs, and if they don't have a clue, I can provide some estimations. |
…move_fixed_ccs_to_fixed_shares
…waste_incineration_mac
…into waste_incineration_mac
Purpose of this PR
Addresses issue #274 by adding incineration emissions to
vm_emiIndBase
, such that they can be abated with the chemicals mac curve.Remove parameters
p37_wasteIncinerationCCSshare
,p37_regionalWasteIncinerationCCSshare
and the switchcm_wasteIncinerationCCSshare
accordingly.Type of change
(Make sure to delete from the Type-of-change list the items not relevant to your PR)
Checklist:
remind2
where it was neededforbiddenColumnNames
in readCheckScenarioConfig.R in case the PR leads to deprecated switchesFAIL 0
in the output ofmake test
)CHANGELOG.md
has been updated correctlyFurther information (optional):
Test runs are here:
/p/tmp/jakobdu/remind_wasteIncinerationMAC
Comparison of results (what changes by this PR?):