Techs incorrectly excluded from capacity_factor via map_tec_time

[behnam-zakeri]

It seems in the GAMS formulation some technologies are omitted from capacity_factor, even though defined by the user. These technologies do not have input, output commodity defined and do not appear in relation_activity; that's why they are not in the set map_tec_time, and hence, mapped out from capacity_factor in this equation. I believe this is not correct, as some technologies can play a role with their capacity, e.g., in parameter relation_total_capacity, and should not be excluded from capacity equations if they don't have input/output commodity, or because not appearing in relation_activity.

[behnam-zakeri]

Since this map_tec_time is created in JAVA backend, it's not easy to see how it is calculated.

[khaeru]

Since this map_tec_time is created in JAVA backend, it's not easy to see how it is calculated.

Looking at this code: https://github.com/iiasa/ixmp_source/blob/85ce0616fdca8885f1a2716f7869b486d4b94191/src/main/java/at/ac/iiasa/ixmp/objects/MsgScenario.java#L1466-L1542 it appears indeed the condition is that the key (set of labels for the dimensions of map_tec_time) appears in one or more of input, output, or relation_activity.

Do I understand correctly that the map_tec_time entries should be populated for values in:

• input (current)
• output (current)
• relation_activity (current)
• relation_total_capacity (missing)
• any others?

[khaeru]

A thought on implementation: since the change here is to expand (i.e. to change the set elements from the union of {A, B, C} to the union of {A, B, C, D}), we can implement the full logic in Python using the mechanism introduced in #561/#514. This runs before the Java code linked above. So the Java code linked above becomes redundant; it will simply re-add elements to these mapping sets that have already been added. This would partly address #254.

This approach will not work in other cases where the desired behaviour is not a superset of the behaviour implemented in Java. E.g. here if we wanted to go from union {A, B, C} to union {A, C}, this would not be a viable approach.

[behnam-zakeri]

Thanks @khaeru for the thoughts. I checked this through the equations again. As I understand, map_tec_time is the mapping of technologies to sub-annual time slices. Therefore, we can't add capacity related parameters like relation_total_capacity to this mapping, because capacity is dealt with only at the annual level in the formulation. The use of this mapping in the equation for capacity_factor means that those technologies without input/output commodity, and with no entries in relation_activity do not need capacity_factor. In other words, these technologies can write to the CAPACITY_MAINTENANCE equation, so the model can invest and build them; however, it is not important what their capacity_factor is because their activity is not needed anywhere in the formulation. So my initial impression that it is a bug may not be correct, and I removed the tag. I will check this further and come back if we need to do something.
But I like your general idea if we can change some mapping/masking sets after being created in java. I thought these sets are created when writing the GDX file and there is no chance to edit them in python after being generated in java.