restructure chemical feedstock emissions balancing

[JakobBD]

Fixes remindmodel/development_issues#343.

Probably requires remind2 changes. Who wants to do it? @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q @fschreyer ?

Type of change

(Make sure to delete from the Type-of-change list the items not relevant to your PR)

• Bug fix
• Refactoring
• New feature
• Minor change (default scenarios show only small differences)
• Fundamental change
• This change requires a documentation update

Checklist:

• My code follows the coding etiquette
• I performed a self-review of my own code
• I explained my changes within the PR, particularly in hard-to-understand areas
• I checked that the in-code documentation is up-to-date
• I adjusted the reporting in remind2 where it was needed
• I adjusted forbiddenColumnNames in readCheckScenarioConfig.R in case the PR leads to deprecated switches
• All automated model tests pass (FAIL 0 in the output of make test)
• The changelog CHANGELOG.md has been updated correctly

Further information (optional):

• Test runs are here: /p/tmp/jakobdu/remind_temp2/output/testOneRegi
• Comparison of results (what changes by this PR?):

[fschreyer]

I don't really see yet how this resolves the issue.

You now added all plastics and incineration carbon to the emissions. However, non-fossil incineration and plastics should not cause emissions (stored plastics should even account negative emissions). Note that the FE emissions factors are 0 (and not negative) here. We could maybe subtract all v37_FeedstocksCarbon in q_emiTeDetailMkt if we want to go your direction.

Let's take a step back and discuss first the urgency and implementation plan.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Let's take a step back and discuss first the urgency and implementation plan.

Lavinia sounded urgent …

• vm_emiTeDetailMkt is calculated using pm_emifac and so is 0 for entySeBio and entySeSyn, and > 0 for entyFeFos
• from that, the carbon content of produced plastics is subtracted, vm_plasticsCarbon, which is calculated using p37_FeedstockCarbonContent, and which is positive for all entyFe
• so this is 0 for fossils and negative for biomass/synfuels
• then, emissions from plastic waste incineration, vm_incinerationEmi, is added, also calculated using p37_FeedstockCarbonContent
• so
  • fossils have positive vm_emiTeDetailMkt, minus positive vm_plasticsCarbon, plus positive vm_incinerationEmi if burned:
    so positive emissions when burned, zero when sequestered
  • biomass/synfuels have zero vm_emiTeDetailMkt, minus positive vm_plasticsCarbon, plus positive vm_incinerationEmi if burned:
    so zero emissions when burned, negative when sequestered
• correct?

[JakobBD]

You're describing my implementation, right?
So yes, I agree, that's what's happening. So everything should by correctly balanced.
By the way, I based this implementation on a strategy I proposed to the two of you (@fschreyer and @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q) in a private chat a while back, and the suggestion got a thumbs up from both of you.

[fschreyer]

Ok, I understand it now and seems fine to address the first (more important) issue raised.

If you replace vm_plasticsCarbon in q_emiTeMkt by v37_FeedstocksCarbon and add all unknownFate emissions in the equation that should solve the second one, too. Right? Maybe then simply remove the unknownFate switch and always account those emissions. Otherwise, another case distinction would be needed.

[JakobBD]

If you replace vm_plasticsCarbon in q_emiTeMkt by v37_FeedstocksCarbon and add all unknownFate emissions in the equation that should solve the second one, too. Right?

Yes. I think that should work.

Maybe then simply remove the unknownFate switch and always account those emissions. Otherwise, another case distinction would be needed.

Why would an additional one be needed? Can't we just leave everything as is and just do your proposed changes?

We could also change that switch a share. To me, a fraction being emitted seem more likely than the two options all or nothing.
The problem is always that there is no abatement option for these.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

JakobBD#7

[fschreyer]

Problem is that I agree to everything after 4 pm...

fossils have positive vm_emiTeDetailMkt

That's not true for fossil feedstocks as they get subtracted here:

  + sum(se2fe(enty,enty2,te),
      pm_emifac(t,regi,enty,enty2,te,enty3)
    * sum(sector$(    entyFe2Sector(enty2,sector)
                  AND sector2emiMkt(sector,emiMkt) ),
        vm_demFeSector(t,regi,enty,enty2,sector,emiMkt)
        !! substract FE used for non-energy purposes (as feedstocks) so it does
        !! not create energy-related emissions
      - sum(entyFE2sector2emiMkt_NonEn(enty2,sector,emiMkt),
          vm_demFENonEnergySector(t,regi,enty,enty2,sector,emiMkt))
      )
    )
  )

So, this feedstock correction would need to be removed in q_emiTeDetailMkt. Then, the implementation should be in analogy to industry CCS.

Why would an additional one be needed? Can't we just leave everything as is and just do your proposed changes?

You are absolutely right.

(unless I change my mind in a few hours)

The problem is always that there is no abatement option for these.

No other abatement option than using non-fossil feedstocks in the first place.

Now that I understand that we account them correctly, I don't mind any share between 0 and 1.

Ok, so let's check again the interfaces of the feedstocks to the emissions equation (assuming vm_demFENonEnergySector substraction in q_emiTeDetailMkt is removed and we do the proposed unknownFate changes). And I like Michaja's logic for that:

(see here for spreadsheet version)

Looks fine to me.

Case	vm_demFeSector * pm_emifac(fos)  (add to q_emiTeDetailMkt)	v37_feedstocksCarbon (substract from q_emiTeMkt)	vm_incinerationEmi (add to  q_emiTeMkt)	vm_feedstockEmiUnknownFate (add to q_emiTeMkt)	vm_incinerationCCS -> vm_co2CCUshort  (add to  q_emiTeMkt)	Total
We produce a fossil plastic bag and burn it	1	-1	1	0	0	1
We produce a bio-plastic bag and burn it	0	-1	1	0	0	0
We produce a fossil plastic bag and keep it forever.	1	-1	0	0	0	0
We produce a bio-plastic bag and keep it forever.	0	-1	0	0	0	-1
We produce a fossil plastic bag and burn it, capture the CO2 and store it.	1	-1	0	0	0	0
We produce a bio-plastic bag and burn it, capture the CO2 and store it.	0	-1	0	0	0	-1
We produce a fossil plastic bag and burn it, capture the CO2 and use it (CCU).	1	-1	0	0	1	1
We produce a bio-plastic bag and burn it, capture the CO2 and  and use it (CCU).	0	-1	0	0	1	0
We produce some fossil Aspirin and they dissolve into thin air (vm_emiUnknownFate > 0 )	1	-1	0	1	0	1
We produce some bio-Aspirin and they dissolve into thin air (vm_emiUnknownFate > 0 )	0	-1	0	1	0	0
We produce some fossil Aspirin and keep them forever (vm_emiUnknownFate = 0 )	1	-1	0	0	0	0
We produce some bio-Aspirin and keep them forever (vm_emiUnknownFate = 0 )	0	-1	0	0	0	-1

[JakobBD]

That's not true for fossil feedstocks as they get subtracted here:

Damn it, you're right.

So, this feedstock correction would need to be removed in q_emiTeDetailMkt.

You had objections to that, and very rightly so. I quote from mattermost:

vm_demFENonEnergySector × pm_emifacNonEnergy are proces emissions, that are added at a different aggregation step (q_emiAllMkt = Emi|CO2 ) and shouldn't be containd in Emi|CO2|Energy.

Sooooo...

• I suggest introducing a variable feedstockEmissions where we compile everything, positive or negative. I will update your table, I find it very useful.

But after thinking about this, I first need a bio-aspirin now, and I will not keep it forever.

[JakobBD]

I updated the table. My solution would be:

• q_emiTeDetailMkt as it was before (non-feedstock emissions)
• q_emiTeMkt:

- v37_feedstocksCarbon(bio,syn) 
+ vm_incinerationEmi(all) 
+ vm_feedstockEmiUnknownFate(all)

That summation follows the balance after each step in the product's lifecycle:

• During production negative emissions for bio and synfuel
• At the end of lifetime, positive emissions when burned without CCS or aspirin dissolves, each of them irrespective of carbon source.

[JakobBD]

Haha we I oversaw one term:

    !! non energy emi from chem sector (process emissions from feedstocks):
  + sum((entyFE2sector2emiMkt_NonEn(entyFe,sector,emiMkt),
         se2fe(entySe,entyFe,te)),
      vm_demFENonEnergySector(t,regi,entySe,entyFe,sector,emiMkt)
    * pm_emifacNonEnergy(t,regi,entySe,entyFe,sector,emi)
    )

I think that's lubricant oil that gets burned, and the like

My suggestion for that would be:

1. ) Change their values, which are so far

pm_emifacNonEnergy(ttot,regi,"sesofos", "fesos","indst","co2") = f_nechem_emissionFactors(ttot,regi,"solids")  / s_zj_2_twa;
pm_emifacNonEnergy(ttot,regi,"seliqfos","fehos","indst","co2") = f_nechem_emissionFactors(ttot,regi,"liquids") / s_zj_2_twa;
pm_emifacNonEnergy(ttot,regi,"segafos", "fegas","indst","co2") = f_nechem_emissionFactors(ttot,regi,"gases")   / s_zj_2_twa;

to

pm_emifacNonEnergy(ttot,regi,"fesos","indst","co2") = f_nechem_emissionFactors(ttot,regi,"solids")  / s_zj_2_twa;
pm_emifacNonEnergy(ttot,regi,"fehos","indst","co2") = f_nechem_emissionFactors(ttot,regi,"liquids") / s_zj_2_twa;
pm_emifacNonEnergy(ttot,regi,"fegas","indst","co2") = f_nechem_emissionFactors(ttot,regi,"gases")   / s_zj_2_twa;

(removing the SE dimension)

2.) Move them into the same feedstocks balance as the terms above
3.) remove feedstocksEmiUnknownFate, it seems to be covered by that?

[JakobBD]

Follow-up question though:

All the feedstocks stuff is currently in q_emiTeMkt. Shouldn't it be moved to q_emiAllMkt??
Like: Are there any parts of the feedstocks emissions balance (positive or negative) that should be accounted in Emi|CO2|Energy?

[fschreyer]

It is gonna be 4 pm soon...so I can only react briefly

(not only because my head does not work reliably afterwards but I also need to get to the Kita).

Some short remarks / questions:

1.)

vm_demFENonEnergySector × pm_emifacNonEnergy are proces emissions, that are added at a different aggregation step (q_emiAllMkt = Emi|CO2 ) and shouldn't be containd in Emi|CO2|Energy.

I don't understand so far how this is related. I was suggesting to remove subtracting the total fossil feedstocks carbon from q_emiTeDetailMkt. Not this process emissions term from q_emiAllMkt. Maybe we misunderstand each other here.

2.) On the chemical process emissions / unknownFate emissions:

My understanding is that feedstocksEmiUnknownFate is carbon in non-plastic products, while vm_demFENonEnergySector × pm_emifacNonEnergy are process emissions during the manufacturing of the products. So, we need both, right?

3. On the accounting to energy or process emissions:

The ultimate place where accounting questions should be decided is in the IAMC template repository. I wanted to open an issue on feedstocks accounting there for a while but have not gotten to it yet.

So far, we accounted all carbon in products to energy emissions in REMIND (only the chemical process emissions were outside Emi|CO2|Energy).

I'd say for waste incineration (for energy purposes), it is clear that is should stay like this (and we now also allocate the waste incineration emissions to different sectors (buildings, industry, power) in reportEmi(). However, you are right that for carbon contained in products it is not so clear whether that seems plausible. The IPCC defines energy-related emissions (sector 1) as emissions from "manufacturing or combustion of fuels". Not sure what this means e.g. for accounting negative emissions from bioplastics. As Philipp said, the real world seems to lack consistent accounting here anyways. There are quite some intricacies e that we discussed also with the relation of gross emissions / net emissions and CDR e.g. if carbon gets accounted negative in one sector and positive in another one.

[fschreyer]

Not sure I fully understand your solution.

I'd interpret it as this and I think that would be fine:

Option A)

• q_emiTeDetailMkt:

- pm_emifac * vm_demFENonEnergySector (only fossil)

• q_emiTeMkt:

- v37_feedstocksCarbon(bio,syn) 
+ vm_incinerationEmi(all) 
+ vm_feedstockEmiUnknownFate(all)

• q_emiAllMkt:

pm_emifacNonEnergy * vm_demFENonEnergySector (only fossil)

(this needs to be only fossil because process emissions from bio/syn products are not accounted as emissions)

Personally, I'd favor also taking out this foss/non-fossil distinction in the feedstock terms for q_emiTeDetailMkt and q_emiTeMkt in analogy to vm_emiIndCCS. This would mean removing the pm_emifac * NonEnFE subtraction of fossil carbon in q_emiTeDetailMkt such that vm_emiTeDetailMkt are emissions including fossil feedstock carbon (how it used to be before Simon's implementation). Then, we can subtract all carbon of v37_feedstocksCarbon in q_emiTeMkt. So:

Option B)

• q_emiTeDetailMkt: pm_emifac * vm_demFeSector (only Fossil) (this term would include feedstocks in FE and hence in emissions)

• q_emiTeMkt:

- v37_feedstocksCarbon(all)
+ vm_incinerationEmi(all) 
+ vm_feedstockEmiUnknownFate(all)

• q_emiAllMkt:

pm_emifacNonEnergy * vm_demFENonEnergySector (only fossil)

Does that make sense?

(I also updated the table)

(It's late)

[JakobBD]

You did it again, after 4 pm :-D

Option B) is wrong I think: Compared with Option A) you add pm_emifac * vm_demFENonEnergySector (fossil) (in q_emiTeDetailMkt), but you subtract v37_feedstocksCarbon(fossil), which is (pm_emifac-pm_emifacNonEnergy) * vm_demFENonEnergySector (fossil), so you'd have a double accounting of process emissions. You could remove that double accounting by removing that term in q_emiAllMkt, but that was what we didn't want, because process emissions are then accounted as part of Emi|CO2|Energy.

Option A) seems like a possible way to go. However, I see a few issues in the splitting between energy and non-energy emissions that we should be aware of:

• vm_feedstockEmiUnknownFate seems like clearly non-energy emissions (the fossil aspirin dissolving into thin air)
• negative emissions for the bio-plastic bag that stays in a landfill forever are now accounted for as negative energy emissions. Do we want that, or do we want that to be negative non-energy emissions?

So I'd propose an option C), which has the exact same terms as option A), but distributes them differently over emeiTeMkt and emiAllMkt. This option looks uglier, but is closest to the desired split imo:

Option C)

• q_emiTeDetailMkt:

- pm_emifac * vm_demFENonEnergySector (only fossil)

• q_emiTeMkt:

+ vm_incinerationEmi(fos) 

• q_emiAllMkt:

pm_emifacNonEnergy * vm_demFENonEnergySector (only fossil)
- v37_feedstocksCarbon(bio,syn) 
+ vm_incinerationEmi(bio,syn) 
+ vm_feedstockEmiUnknownFate(all)

With this option, the following is ensured:

• negative emissions of biomass-products (plastic and non-plastic) are landfilled or burned with CCS non-energy. That's what we want, right?
• fossil aspirins dissolving into thin air are non-energy emissions.
• There are no cases where emissions are counted as positive in one equation and negative in another. This is also the case in Option A), but not in intermediate ones (where, for example, we only move vm_feedstockEmiUnknownFate to emiAllMkt, or leave all incineration emissions in emiTeMkt)

As mentioned earlier, we could (and should) sum these terms in the industry modules to variables with names that other people can intuitively understand, and then add these terms to the core emission balance.

[fschreyer]

I don't discuss this issue before 8 pm... ;-)

Option B) is wrong [...] you'd have a double accounting of process emissions

Right. I agree. So option A or C are correct.

On the question what to account in which equation

For all levels below Emi|CO2|+Energy, emissions are calculated bottom-up in reportEmi() anyways. There are no emissions variables for that in REMIND. vm_emiTeMkt is then already quite close to the energy-related emissions we report, but actually need a few corrections due to our current unfortunate structure of emissions and carbon flows in REMIND. Finally, vm_emiAllMkt actually maps one to one to Emi|CO2, Emi|CH4 etc. (with the exception that bunkers are excluded). That means, technically, it is not critical to correctly spread the terms across the emissions equations in REMIND but obviously it makes sense to fit all energy-related emissions into vm_emiTeMkt for some consistency.

Now, conceptually on the accounting:

Ultimately, these decision should be made on IAMC level and they should based on (the more general) accounting rules of the IPCC. In my perception, these kind of accounting questions of carbon in materials are not fully clarified (neither in IAMC, IPCC or EU-ETS). We should decide for something that seems sensible for now but then open an issue in the IAMC common definitions repository.

I'd say this:

• vm_incinerationEmi(fossil) - vm_incinerationCCS(non-fossil): all (fossil) waste incineration emissions and (non-fossil) waste incineration CCS should go into Emi|CO2|+|Energy as waste incineration (for energy purposes) is accounted under IPCC sector 1 (Energy Supply BECCS is also accounted negative in energy emissions)

• pm_emifacNonEnergy * vm_demFeSector obviously goes under Emi|CO2|Industrial Processes|+|Chemicals (industrial process emissions are in IPCC sector 2)

• Now, fossil non-plastic waste emissions (vm_feedstockEmiUnknownFate(fossil)) and CDR from stored materials (v37_plasticWaste * (1-pm_incinerationRate)) are a bit unclear. However, one could put them under Emi|CO2|+|Waste. The waste sector reflects IPCC sector 4 which accounts all kinds of emissions on landfills and waste incineration sites (where energy is not recovered, like open burning and stuff). Apparently, carbon stored in waste disposal sites is already accounted as a memo item in this sector which means that it can be reported for information but is not mandatory for states to report and not added to the totals of the waste sector (if I understand correctly). But it gets subtle here. Urea used as fertilizer seems to be accounted under agriculture (IPCC Sector 3H). I don't think we need this level of detail, though, at the moment.

Hope that makes sense. My proposal would be that this would be three separate terms of the feedstocks implementation that get fed back to the emissions equations individually (the first in q_emiTeMkt, the second and third in q_emiAllMkt).

See this for the general structure of the IPCC sectors and the waste sector specifically (IPCC 2006 Guidelines, Volume 5, Chapter 1, Intro):

[JakobBD]

I'm trying to translate this into concrete implementation:

Compared with my option C), I'm adding vm_incinerationCCS(bio,syn) to q_emiAllMkt and subtracting it from q_emiTeMkt. This results in:

• q_emiTeDetailMkt:

- pm_emifac * vm_demFENonEnergySector(fos)

• q_emiTeMkt:

+ vm_incinerationEmi(fos) 
- vm_incinerationCCS(bio,syn)

• q_emiAllMkt:

pm_emifacNonEnergy * vm_demFENonEnergySector(fos)
- v37_feedstocksCarbon(bio,syn) 
+ vm_incineratedPlastics(bio,syn) !! new variable, equals vm_incinerationEmi(bio,syn) + vm_incinerationCCS(bio,syn)
+ vm_feedstockEmiUnknownFate(all)

I would implement that in GAMS, and you adapt reportEmi?

[fschreyer]

This

- v37_feedstocksCarbon(bio,syn) 
+ vm_incineratedPlastics(bio,syn) !! new variable, equals vm_incinerationEmi(bio,syn) + vm_incinerationCCS(bio,syn)
+ vm_feedstockEmiUnknownFate(all)

equals what is currently

-vm_nonIncineratedPlastics(bio,syn) + vm_feedstockEmiUnknownFate(fos)

right?

I would not use these terms in such a complicated manner, but rather the latter ones for ease of understanding. And this term would then go to Emi|CO2|+|Waste, if I see correctly. I would say that works out.

I would implement that in GAMS, and you adapt reportEmi?

Alright. But I cannot promise this very soon at the moment. Will be a bit lower on the list.

[JakobBD]

They're only equal with our current default switches:

• If cm_feedstockEmiUnknownFate is turned off, bio-carbon in landfilled aspirin does not count as negative emissions in the simplified version. This was actually your second point in issue #343, if I understand correctly.
• If cm_wastelag is switched on (which we will do at the latest when coupling to the MFA), the accounting is also incorrect in the simplified version, but hopefully correct in mine.

And the difference is one variable, seems worth it to stick to that?

[JakobBD]

Needs remind2 adaptation before merging. @fschreyer, please review!

[LaviniaBaumstark]

is this PR also relevant for our next release? Will it be merged soon?

[JakobBD]

no

[fschreyer]

I would have some time for this now. Would you mind pulling develop and making a run with this, @JakobBD? Then, I'd do the reporting change.