Add variant/module for cooling technologies in tools.costs

[measrainsey]

Add a variant/module to project costs for cooling technologies

This PR adds a new module within tools.costs called cooling. @adrivinca has provided input data for these technologies -- these technologies are currently all mapped to a technology in the energy module (based on the assumption that these cooling technologies are sort of addons that follow the same regional differentiation as their non-addon counterpart). However, the cooling technologies have their own base year reference region costs.

This PR's branch is derived from the costs/reduction-year branch, which has its own PR #227. Once that one is merged, I will rebase.

How to review

For @adrivinca: Verify if the implementation is correct and if the outputs make sense.

For @khaeru and/or @glatterf42 : Read the diff and note that the CI checks all pass.

PR checklist

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

[adrivinca]

Thanks @measrainsey for advancing this work!
We tried and it seems it works well for what concerns the cooling techs.

just a note for the general module that could maybe improved with a fix or just notified to developers: One limitation of the fix cost generator is that is does not take into account of the technology lifetime in the vintage-activity years. This way the output dataframe is way larger than actually needed and might take up space. (for example with cooling technologies with 30 years lifetime) the fix_cost df would be five time smaller than the actual one.

I understand that including the lifetime in the process would require adding the information in the initial data, and maybe we don't want it.
Otherwise I would suggest write a note about it and the users one could post-apply some formulas like in message_ix_models.model.water.util.map_yv_ya_lt() and just filter the output

[measrainsey]

Thanks @measrainsey for advancing this work! We tried and it seems it works well for what concerns the cooling techs.

just a note for the general module that could maybe improved with a fix or just notified to developers: One limitation of the fix cost generator is that is does not take into account of the technology lifetime in the vintage-activity years. This way the output dataframe is way larger than actually needed and might take up space. (for example with cooling technologies with 30 years lifetime) the fix_cost df would be five time smaller than the actual one.

I understand that including the lifetime in the process would require adding the information in the initial data, and maybe we don't want it. Otherwise I would suggest write a note about it and the users one could post-apply some formulas like in message_ix_models.model.water.util.map_yv_ya_lt() and just filter the output

Sorry I forgot to respond to this comment/review here as Adriano and I had a side conversation about this topic! But I'll put my thoughts here anyways to preserve them on this platform. Additionally, this issue of lifetime was also brought to my attention by Oliver, so I might have to address this at some point.

While my initial thoughts/feelings was to keep technology lifetime outside of this tool so that the tool can remain agnostic to so many inputs/parameters (as perhaps technology lifetimes can vary across scenarios, hypothetically) and as lean as possible, I can see that keeping costs projection for a technology beyond its lifetime can (a) cause confusion and (b) lead to very large output dataframes, like Adriano mentioned.

It seems the best way to make sure lifetimes and vintages are accounted for would be to have the tool call upon the vintage_and_active_years() function from a scenario object. Given that at the moment the costs tool does not interact with MESSAGEix scenario objects at all (this is done by the user post-tool), I would like to leave this issue of lifetimes as a larger TODO on my list and not have it addressed within this PR.

[measrainsey]

We also have ScenarioInfo.yv_ya. The ScenarioInfo class (and the .water.utils function mentioned by @adrivinca) are specifically for working with data in the absence of (e.g. before the creation of) a concrete Scenario object, so I think this is quite possible. But it's also fine to omit it from this PR and leave a note at an appropriate place in the docs like:

.. note:: The data produced are for all valid combinations of :math:`(y^V, y^A)`—including those that are beyond the `technical_lifetime` of the |t| to which they apply.
   This may produce large data frames.
   If this is problematic, user code **may** filter the data for valid combinations.

Thanks @khaeru for your suggestion. I have created an issue #237 to track progress on this, and for the time being, I have added a note in the documentation:

message-ix-models/doc/api/tools-costs.rst

Lines 151 to 154 in 70db1b2

	.. note:: The data produced are for all valid combinations of :math:`(y^V, y^A)`—including those that are beyond the `technical_lifetime` of the |t| to which they apply.
	This may produce large data frames, depending on the number of technologies, regions, and scenarios.
	At the moment, :mod:`.tools.costs` does not filter out these combinations.
	If this is problematic, the user may consider filtering the data for valid combinations of :math:`(y^V, y^A)`.

[khaeru]

Looks good to me. @glatterf42 was there anything else you were waiting to see here, or can I merge?

[glatterf42]

Nope, good from my side :)

[measrainsey]

Hi all, thanks for approving the PR!

Just a quick note that this branch is based off of the branch in #227, so that PR should probably be approved and merged before this one, I presume?

[glatterf42]

You could also merge this PR into the branch it originated from. This would increase the size of the other PR, but we could focus on the changes not already reviewed.
However, as far as I can tell, the other PR is already quite close to being merged, so I don't think it hurts to wait before merging this one.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.5%. Comparing base (2dbdec6) to head (687c4c4).
Report is 13 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #222     +/-   ##
=======================================
- Coverage   75.5%   75.5%   -0.1%     
=======================================
  Files        203     203             
  Lines      15503   15503             
=======================================
- Hits       11707   11706      -1     
- Misses      3796    3797      +1     

Files with missing lines	Coverage Δ
message_ix_models/tests/tools/costs/test_decay.py	100.0% <100.0%> (ø)
message_ix_models/tests/tools/costs/test_gdp.py	100.0% <100.0%> (ø)
...ge_ix_models/tests/tools/costs/test_projections.py	100.0% <ø> (ø)
...tests/tools/costs/test_regional_differentiation.py	100.0% <100.0%> (ø)
message_ix_models/tools/costs/config.py	97.2% <100.0%> (ø)
..._ix_models/tools/costs/regional_differentiation.py	97.9% <ø> (ø)

... and 1 file with indirect coverage changes