Reporting of variables for different versions of technology not possible.

[HauHe]

The IAMC format allows to report variables for different types of a technology, e.g. Capital Cost for Solar PV: Capital Cost|Electricity|Solar|PV|2, ... Capital|Cost|Electricity|Solar|PV|N
Currently these variables can't be reported using the openentrance package. While this can be acceptable for variables like Capacity, this potentially limits the comparability of data between models.
My suggestion to address this issue would be to add a definition like the below to definitions\variable\technology\technologies.yaml:

- Capital Cost|Electricity|{Electricity Input}|{Technology Type Tag}:
    description: Capital cost for {Electricity Input} for {Technology Type Tag}
    unit: [EUR_2020/kW, USD_2010/kW]
    skip-region-aggregation: true

For implementing this a file definitions\variable\tag_technology_type.yaml would need to be created. The type tags would consist of numbers.

An alternative route could be to create the possibility to expand and use for example the tags in tag_variable_renewable_power_type.yaml

I don't know if there has been already any discussion on this, therefore I'd be happy discuss what are the pros and cons for the different options.

[danielhuppmann]

I agree that adding these different technology types is useful, but I'd be hesitant to (re)introduce a generic numering, because this is not very useful and requires a separate mapping for the id to the actual technology type. Better to add the relevant technology types explicitly.

[HauHe]

@FLomb, in your case we are talking about Solar PV. Would it help to have utility scale and rooftop? Or do you consider panels that adjust their angle to the sun and similar?

[danielhuppmann]

When thinking about adding different technology types, please follow the list at the common-definitions repository - or suggest changes to that list.

For context, the aim of the common-definitions repository is to have one list of variables that can be used across numerous projects, based on harmonized and cleaned versions of NAVIGATE, ENGAGE, openENTRANCE, etc.

[HauHe]

Question on this @danielhuppmann, if we want to use a common definition, should we add it to the definitions in openentrance?
I see that the list in common-definitions is more extensive than in the openentrance

[danielhuppmann]

Yes, please - for the time being, we have to manually keep these repos consistent, because openentrance has too many variables and some non-smart choices were made. But once common-definitions is mature, we can implement some automated translation and merge them.