Non-integer technical_lifetime → error in scaling_investment_costs.gms

[khaeru]

If technical_lifetime has non-integer values, the calculation of beyond_horizon_factor in scaling_investment_costs.gms errors:

message_ix/message_ix/model/MESSAGE/scaling_investment_costs.gms

Line 139 in 38461e6

( 1 - POWER( 1 / ( 1 + interestrate(last_period) ), beyond_horizon_lifetime(node,inv_tec,vintage) ) )

…with a message like:

**** Exec Error at line 2056: power: FUNC DOMAIN: pow(x,i), i not integer

The i argument is beyond_horizon_lifetime, which is computed in the same file:

message_ix/message_ix/model/MESSAGE/scaling_investment_costs.gms

Lines 10 to 12 in 38461e6

	* compute the technical lifetime remaining beyond the overall model horizon
	beyond_horizon_lifetime(node,inv_tec,vintage)$( map_tec(node,inv_tec,vintage) ) =
	technical_lifetime(node,inv_tec,vintage) - remaining_years(vintage) ;

When technical_lifetime is real/non-integer, this parameter will also be non-integer.

Because it's not mentioned in the documentation, it's not clear (cf. related issues, below) whether other parts of the GAMS code also expect technical_lifetime to be only integer numbers of years. Conceptually, this restriction doesn't make any sense, but practically the code may have been written that way.

For this particular error, a fix would be to use the GAMS ** operator, which accepts real exponents, instead of the POWER() function, which does not. The line can also be simplified since (1 / (1 + i))**b is just (1+i)**(-b).

Notes:

• Discovered with @francescolovat working with the code in message_data.model.transport.data.ikarus, which reads a source file with a technical lifetime for some technologies of 14.7 years.
• Loosely related issues:
  • Sanity check for technical_lifetime correct? #137
  • Problems to represent an existing technology #376
  • Document duration_period & related params #385