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.