Add DACCS and CCS infrastructure model

[ywpratama]

This PR adds DACCS and modifies the CCS infrastructure representation in MESSAGEix for ScenarioMIP. It includes a set of functions to perform the task, as well as the necessary data provided in YAML files. Currently, several functions still need docstrings for proper documentation.

How to review

• Read the diff and verify that all CI checks pass.
• Ensure that all new functions have proper docstrings explaining their purpose.

PR checklist

• Continuous integration checks all ✅
• Add or expand tests; coverage checks both ✅
• Add, expand, or update documentation. Deferred → Document and improve .tools.add_dac #444
• Update doc/whatsnew.

[codecov]

Codecov Report

❌ Patch coverage is 71.71053% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.7%. Comparing base (3f52423) to head (67854b9).
⚠️ Report is 42 commits behind head on main.

Files with missing lines	Patch %	Lines
message_ix_models/tools/add_dac/__init__.py	67.4%	43 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #419     +/-   ##
=======================================
- Coverage   74.7%   74.7%   -0.1%     
=======================================
  Files        270     272      +2     
  Lines      22312   22463    +151     
=======================================
+ Hits       16676   16784    +108     
- Misses      5636    5679     +43     

Files with missing lines	Coverage Δ
...sage_ix_models/tests/project/ssp/test_functions.py	100.0% <100.0%> (ø)
message_ix_models/tools/wb.py	30.6% <100.0%> (ø)
message_ix_models/tools/add_dac/__init__.py	67.4% <67.4%> (ø)

... and 22 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[khaeru]

Thanks for starting this draft!

Some quick reactions—these may be off the mark, since I am just guessing by looking at the Git history and changes:

• To make work easier, it will be good to have at least 1 minimal test that runs the added code—even if the outcome of that test is an XFAIL. It seems one (the main?) entry-point is .project.ssp.script.util.functions.add_ccs_setup(). If that's accurate, a minimal test could simply call this function with an empty Scenario or bare RES scenario. A slightly better test would add some contents to that empty/bare scenario so that the function runs without error, or at least partway through. See Add GEIDCO IV extended features and documentation #383 where @yiyi1991 did something similar.

• With such a test in place, it will be easier to address the code quality failures, particularly the ones about excessive complexity in add_ccs_setup() and .tools.add_dac.generate_df().

• I see there are a number of large YAML files with mixed configuration/data, and that these eventually go into .tools.add_dac.add_tech(). Like in Add new industry reporter #395 (@macflo8's PR) and again Add GEIDCO IV extended features and documentation #383, it will be good to have some code or a class that reads these files, separate from where they are used. The reason for this is to distinguish and clarify 2 things:

  1. The particular layout of these files/their format, and
  2. What kind of information the code (e.g. add_tech()) needs.

  Having these 2 things described would make it more realistic to re-use the code by supplying different information (2) and for others to modify the files (or derive new files) and ensure they contain the needed information in a valid format (1). It will also help towards simplifying add_tech() by separating config-/file-parsing logic from the model-building logic.

• I am not clear what the distinction is between:

  • Generic capability for adding DACCS representation to MESSAGEix-GLOBIOM family models.
  • A “standard representation” (if there is one) of DACCS in the family—i.e. is this the main/preferred/only way to do it, or might there be others?
  • The particular application or parametrization (numbers) used with the above in the context of the ScenarioMIP project.
  • A standard parametrization, e.g. if someone is creating a SSP1-based scenario with DACCS outside of the ScenarioMIP project, which data/config they should use, and whether this is distinct from that used within ScenarioMIP.

  I think we can clarify these via some discussion, that could then be summarized in documentation. They may also lead us to rename/move code, e.g. .tools.add_dac might be more properly named .model.dac if it contains a ‘standard’ representation that should always be used with MESSAGEix-GLOBIOM (just as .model.material contains the ‘standard’ way of representing materials and industry, etc.)

Of course, I'm happy to help or bring in colleagues on any or all of these points.

[Tyler-lc]

Thanks for the PR on the DAC and CCS :)
Right now there is a broken link between the h2_elec and meth_h2.
As of now h2_elec has three modes: M1, feedstock and fuel.
The addon_conversion technology that connects the electrolyzers to meth_h2 has also the same three modes
The issue is that meth_h2 takes carbon from three different sources: fic, dac, bic.
So in meth_h2 we have the following modes: feedstock_bic, feedstock_fic, feedstock_dac, fuel_bic, fuel_fic, fuel_dac.
Basically right now, because the different naming structure in the modes of h2_elec, addon_conversion and meth_h2, the two technologies are not connected.
Somewhere in between this linkage broke.
@macflo8 Should know a little bit more on the topic. We have discussed it in person already (also he brought this PR to my attention).

[khaeru]

@macflo8 and I discussed that it is important to merge this PR in order to (a) reduce #235 to zero or few commits, such that that PR can be closed, and (b) allow other work to proceed from main. Since @ywpratama is on leave until 4 November, we will:

• Accept the codecov/patch check failure with the partial test added on this branch.
• Create a follow-up issue to add the documentation missing from this PR.
• Rebase after Confirm support for Python 3.14, drop 3.9 #443, approve, and merge.

[khaeru]

Thanks @ywpratama and @macflo8 for the work here.

I did the following:

• Opened #444 to note the need for a follow-up PR that adds the missing documentation.
• Reworded some commit messages to match the code style (capitalization, typos).
• Added one commit to mention the new module and tested function in the “What's new,” as required by the PR checklist.

With these, and the above caveats, we can now merge this.

[macflo8]

Thanks @khaeru for adding the missing pieces required for the merge!