Improve IAMCConversion

[khaeru]

Closes #454.

How to review

TBA

PR checklist

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

[yiyi1991]

Surprisingly found that input c + l and output c + l are not enough to describe a group of technologies in the current version.

I tried to use it to get a group of "fossil power generation" technologies, which worked well.
Then I moved on to "solar power generation" technologies. I found that the solar_res_*s in the current model version do not use input at all, and they are also not the only technologies that do not use input (also winds).

Maybe it is not a bad idea to add dummy commodity input or real ones (to get proper Primary Energy|Solar).

[khaeru]

I found that the solar_res_*s in the current model version do not use input at all, and they are also not the only technologies that do not use input (also winds).

Maybe it is not a bad idea to add dummy commodity input or real ones (to get proper Primary Energy|Solar).

That could be one way to do it.

Other options—not necessarily mutually exclusive:

1. Add function(s) that call get_technology_groups() and then further process the return values to add, modify, remove, combine, etc. So for instance, one could take one of the lists and filter only entries like name.startswith("solar_res") or similar.
2. Add extra "annotations" and to technology.yaml:

   solar_res1:
     name: solar_res1
     description: Maximum solar electricity potential 1
     type: secondary
     sector: electricity
     output: [electr, secondary]
     groups: ["solar res", "foo", "bar"]

   …and improve get_technology_groups() to add such tech IDs to the named groups.
3. Add extra 'parent' technologies with 'children' to technology.yaml:

   SOLAR RES:
     name: Group of all solar potential technologies
     child: [solar_res1, solar_res2, ...]

   (This is done in the transport technology.yaml, for instance here, but not yet in the 'main' one.)
   get_technology_groups() can then understand that "SOLAR RES" should not be added to the Scenario's technology set, but should be interpreted as/included in the list of groups.

In the case of (2), (3), and the "dummy" inputs, the information still lives in the YAML file; in (1) the information is produced by code. So I would prefer the former for that reason.

Can you give any example(s) (1 or more) of groups of technologies that need to be available? I can add them to the tests and then make sure that the code can produce them.

[yiyi1991]

Ah thanks. The 2 and 3 make quite much sense. We should avoid making gdx bigger indeed.
I was basically going through the technology groups sitting in lhs/rhs here.

https://github.com/iiasa/message_data/blob/dev/data/policies/default_config.yaml#L810-L881

Will come back with examples once I finish.