CCS and DAC updates

[ywpratama]

This PR has 2 updates:

1. Remove operation reserve potential for DAC. The values are for electricity storage-equipped DAC but this variant is removed in this implementation
2. Update injection rate for CO2 according to the recent tests and agreed values
3. Switch 'co2trans' and 'commodity' values for consistency. No changes on the resulting .gdx file are expected. CO2_cc plus co2 output values must equal to 1.

How to review

Required: describe specific things that reviewer(s) must do, in order to ensure that the PR achieves its goal.
If no review is required, write “No review:” and describe why.

PR checklist

• Continuous integration checks all ✅
• Add or expand tests; coverage checks both ✅
• Add, expand, or update documentation.
• Update doc/whatsnew.

[gidden]

@ywpratama it likes also leakage assumptions have changed?

I see that co2_trans and stor_co2 have output efficiencies of 99%. I presume this means a 1% leakage rate? If so, that would be good to add as a comment. It would also be good to make a comment on relation_activity_CO2_cc stating that the assumption there (1%) and the assumption in the output efficiency must add to 1.

[gidden]

Also, if I look at the input/output flows, it seems co2_stor can output dac_co2 to the level useful. This seems like the wrong technology to do this, right? I would expect co2_trans to output to two different technologies: storage and utilization.

The below is how the flow has been described previously, and to the best of my knowledge, that is not how it is implemented here:

cc @macflo8 @OFR-IIASA

[ywpratama]

@ywpratama it likes also leakage assumptions have changed?

I see that co2_trans and stor_co2 have output efficiencies of 99%. I presume this means a 1% leakage rate? If so, that would be good to add as a comment. It would also be good to make a comment on relation_activity_CO2_cc stating that the assumption there (1%) and the assumption in the output efficiency must add to 1.

Hi Matt, the assumption is still the same. I just switched "value" and "commodity scale" so it will be more consistent with other techs.

[ywpratama]

Also, if I look at the input/output flows, it seems co2_stor can output dac_co2 to the level useful. This seems like the wrong technology to do this, right? I would expect co2_trans to output to two different technologies: storage and utilization.

The below is how the flow has been described previously, and to the best of my knowledge, that is not how it is implemented here:

cc @macflo8 @OFR-IIASA

Ah, yes, true. For some reason we used to have "exports" as output for co2 storage. If I remember correctly someone (I forgot who) said it was to track and see if co2 storage actually does some activity. So I wanted to keep it, just in case. I remember now Oliver also questioned this at some point. So, if we don't need it anymore, we can remove it. At the moment co2 "useful" is just floating around doing nothing in the model. CO2 trans output is at level final, which can feed into storage or util.

[OFR-IIASA]

If there is no connection, we can still keep it in the model, but we need to make sure that it cant be used as a free alternative to he storage. You could put a temporary bound_activity_up of 0 on it for example; or comment it out in the yaml file so it just doesnt get generated. A quick fix is acceptable, but we shouldnt forget to refine this later on for e-fuels in the industry/materials sector.

[ywpratama]

Thanks, Oliver. There is no connection there. No technology has useful co2 as input. And for materials, it is specifically use "captured_co2", aggregated by "co2_util". I tested it in some scenarios where methanol production uses captured_co2 and it worked fine. For the fix I can just remove it from co2 storage output in the yaml file if that's what we agree to do.

[OFR-IIASA]

sounds fine to me.

[ywpratama]

@macflo8, @OFR-IIASA, @gidden, thanks for all the comments. CO2 useful is now removed from the output. @gidden, for the "hardcoded" values issue, I am afraid it requires a bit of changes in the "add_tech" function. I know what to changes, but I cannot test it at the moment as I am outside IIASA network. So, perhaps should not take the risk of making the function not working properly at this stage? Happy to implement once I am back

[gidden]

Yes, definitely not blocking, that's why we made an issue - so we remember for the future =). Thanks @ywpratama !

[gidden]

for future reference, these are the lines that define the ssp assumptions of injection limits and storage limits. see issue #267

[ywpratama]

Noted! Thanks!