[aaccensi]

Context

The generic external coupling node for captured CO2 is gone. The CO2 it captured now flows through the refineries transformation node: its emissions input holds the CO2, and its captured input sets the share of those emissions that is captured. A scenario keeps the CO2 it captured when that amount becomes the node's emissions, captured in full.

Implemented changes

Migration setting the value of the external_coupling_industry_external_coupling_node_captured_co2_supply input to the new CO2 capture external coupling inputs:

• external_coupling_energy_chemical_refineries_transformation_external_coupling_node_co2_emissions - old value
• external_coupling_energy_chemical_refineries_transformation_external_coupling_node_co2_captured - to 100%

Note about skipped scenarios

Production data checks showed some scenarios that would not work with the current migration approach so those are being skipped.

• 36 scenarios already have the new input set (most likely all NBNL):
  1450938, 1450943, 1450951, 1450963, 1450965, 1450974, 1450976, 1487681, 1488454, 1489091, 1489984, 1490022, 1490064, 1490067, 1444398, 1444400, 1450945, 1450955, 1488453, 1488563, 1489006, 1489020, 1489082, 1489084, 1489092, 1489466, 1489695, 1489717, 1489737, 1489751, 1489767, 1489995, 1490032, 1490063, 1490065, 1490066
  * Notify NBNL about these scenarios?

• 6 scenarios only have ccus and not industry_chemical_refineries coupling:
  1447832, 1447838, 1447839, 1447840, 1447841, 1447917

Related

This work is a set of 3 PRs:

• etsource: Add co2 capture in industry transformation when coupled to CTM. etsource#3497 (land first)
• etmodel: Add co2 capture in industry transformation when coupled to CTM. etmodel#4825
• etengine: Generic CO2 capture external coupling migration #1820 [this one]

Checklist

• I have tested these changes
• I have updated documentation as needed
• I have tagged the relevant people for review

[noracato]

I like this idea of the reporting. If it helps out the modellers, we can think of adding it somehow to the ETEngine::ScenarioMigration module

[aaccensi]

I like this idea of the reporting. If it helps out the modellers, we can think of adding it somehow to the ETEngine::ScenarioMigration module

That's probably best, and is worth moving it nonetheless. I already reused this method from the previous migration, moving the print_report to the module makes a lot of sense, we can use it or not whenever it makes sense. I personally think that adding a bit of context of what is going on during the migration doesn't hurt (as long as we are no link the reporting to something with a relevant performance impact) and it can help us get a better picture.

[mabijkerk]

@aaccensi when I try this migration locally I get the following:

[mabijkerk]

I now got it to work. Works as expected!