Collective Issue for GAMS related issues

Nobody has claimed this yet.

### What is this about?

The issue is aimed at collecting any known issues related to the GAMS code and their impact on model behavior:

- Technology last year: There is no definitive way to determine the last vintage year of a technology as the `technical_lifetime` which could provide this information, is required to be defined for all activity years in addition to the vintage years to account for relation_activity entries. Hence only by additionally retrieving the `input` and `output`, assuming they are defined correctly, can the end of lifetime be determined.

- Technology inclusion in optimization: Technologies are required to have either of three parameters to be included in the optimization: `input`, `output` or `relation_activity`. But also there are technologies that have `relation_new_capacity` or `relation_total_capacity` entries only or some which are add-on technologies and only have `emission_factor` entries. This means that currently, a lot of excess dummy parameters clutter the model to meet the inclusion requirements (https://github.com/iiasa/message_ix/issues/868).

- Share constraints: For each share total, only a single set of share technologies can be defined. This means that if for single set of technologies i,e. 7 renewable bins, multiple shares need to be defined i.e. for each individual technology, the entire set of shares needs to be redefined multiple 7 times.

- Share constraints can only be defined across the same commodities/modes: A share constraint can only be create based on the same `input` or `output` commodity. This means a share for total final energy cannot be added, unless a dummy commodity is created which accounts for all commodities contributing to total final energy.

- Cost of relation related costs are not included in base technology levelized cost (https://github.com/iiasa/message_ix/issues/667)

- Renewable formulation: Currently there is no parameter to allow for the adding an `activity_lower/upper` or dynamic constraints style bound to the renewable_potential.

- Technical lifetime can only be defined as an integer: due to the current GAMS formulation, adding non-integer technical lifetime results in a gdx compilation error.

- Bound emission can only be defined as an upper-bound: The parameter `bound_emission` should actually be renamed to `bound_emission_up` and an option should be added for adding a `bound_emission_lo`.

- Emission scaling factor: The emission scaling factor seems to only work if it is set to 1; other values are disregarded (tests needed to confirm).

- Share constraints set to zero: Whenever the `share_*_up` is set to zero, as GAMS disregards 0 values, the bound is ignored. An additional parameter `is_share_*_up` is needed (https://github.com/iiasa/message_ix/issues/902).

- Capacity related dynamic constraints: dynamic constraints growth_*_lo/up and initial_*_lo/up as well as corresponding soft constraints can only be assigned for activity and new_capacity for technologies. A similar formulation is also required for total_capacity (https://github.com/iiasa/message_ix/issues/869).

- When using the `slack` for debugging purposes, the options are very limited. First, the SLACK options only cover a limited amount of equations and second of all, there is no option to constraint sets of technologies or regions, which means that the slack will be applied to "all" technologies and "all" regions, often providing more reductions (slack) than actually required (https://github.com/iiasa/message_ix/issues/160).

This is a collective list covering technology lifetimes, optimization inclusion, share constraints, emissions, renewable bounds, dynamic constraints, and slack behavior. Start by reading the linked issues 868, 667, 902, 869, and 160, then trace the relevant GAMS formulation and parameters for one narrowly scoped item. Done should mean that item has an agreed behavior and corresponding validation, but no source file or test is named here.

Written by the indexing model from the issue text.