iiasa / message_ix

The integrated assessment and energy systems model MESSAGEix
https://docs.messageix.org
Apache License 2.0
120 stars 153 forks source link

Sanity check for `technical_lifetime` correct? #137

Open OFR-IIASA opened 5 years ago

OFR-IIASA commented 5 years ago

When generating a model, a sanity check is performed as part of data_load.gms, to ensure "that the economic and technical lifetime are defined and consistent for all investment technologies". When removing all vintage specific data for a technology after the year for which it should not be available anymore e.g. the technology should only be built up until 2020, therefore vintage specific parameters after 2020 are removed, this results in an error when the sanity check is executed.

More details:

In the global message model, there are several technologies which should not be built/available after a certain time period. For these technologies, there is year_vtg specific data for years after which there is no input/output data specified, such as inv_cost, fix_cost etc. E.g. the technology has not input/defined for vintage_years after 2020, but there are still vintage specific parameters defined for 2030 and 2040, the years when the technology can still be active based on the technical lifetime for the vintage 2020 (in this case the technical lifetime is 30 years). Currently, a bound_new_capacity up is also used for 2030/2040, but if this wouldnt be the case, and someone uses the function vintage_and_active_years() to insert data, then this could result in issues because the vintage_and_active_years() function will return activity years all years for which a technical lifetime is provided including those years for which no input/output data is specified.

In order to resolve this issue, either the sanity check needs to be corrected, or the parameter interdependencies need to be looked at to understand why vintage specific parameters are required for years where a technology cant be built.

OFR-IIASA commented 5 years ago

This could also be relevant for an issue previously observed #120