Add variables for capacity additions

[robertpietzcker]

Add variables for capacity additions.

In the process, clarified the subtypes of pumped hydro, and included pumped hydro in storage tags.

Also clarified that "Heat" is "centralized heat generation", and not heat generation in buildings or so. Accordingly, Capacity|Heat|Residential and Commercial|Heat Pumps does not give the capacity of heat pumps in buildings, but rather the capacity of large-scale heat pumps in district heating networks supplying residential&commercial buildings.

[sandrinecharousset]

Hi @robertpietzcker @danielhuppmann , from my point of view, kicking hydro|pumped storage out of electricity tag is a problem as we need to have in this list all the technology which do produce electricity, which Hydro|Pumped Storage does (while a battery will only store electricity which has been produced via another techno). We had discussed that topic last year and chose to keep Hydro|Pumped Storage in electricity tag, as well as in storage tag so that the list electricity gives all technos which produce electricity and the list storages gives all techno which do store electricity. Also changing the name of the techno and removing existing variables will be a problem for all the already existing linkage scripts which are still being used (and will remain used for at least a few year) :-)
Happy to discuss this -)
Best

[robertpietzcker]

Hi @sandrinecharousset, thanks for your comment!
and sorry for (potentially) messing with your reporting - I think I misunderstood Daniel sometime in the past that by now, only ECEMF is still actively using the openENTRANCE template, so I should simply propose any variable changes that we need.

on Pumped Hydro:
To my understanding of the technology definition, pumped hydro does not produce electricity , it only stores electricity produced by some other tech. So it does NOT include any hydro storage that also has external inflow, but ONLY storages where water first has be pumped up to generate any electricity.
This also matches with how Hydro|Reservoir is defined:

Hydro|Reservoir:
      description: hydropower systems with seasonal storage capacity
        (possibly including pumping turbines)

The "possibly including pumping turbines" makes me understand it such that it contains all hydro storage with external inflow - or do you see it differently?

If I remember correctly, eg the IEA does NOT include electricity from pumped hydro in its reporting for hydro, but only the amounts for run-of-river and reservoir.

[sandrinecharousset]

Hi @robertpietzcker and many thanks for your answer!
We are still using the openentrance nomenclature for at least 3 projects in which I am involved, which are not ECEMF :-)

Pumped Hydro is indeed a complex topic for inclusion in such a nomenclature , if you look at the history you may see that there have already been a few loops about it. It was when we started openentrance in Electrcity, then it moved to storage and then back to electricity, and I remember it ad sth to do with electricity production.

regarding the different types of hydropower, it depends on the point of view. But the way it is usually modelled when aggregated at the scale of country is as you say that what is called Pumped Storage is representing the virtual "battery" obtained from hydropower. The definition tells that there may be pumps in the 'Reservoir' category but I think that in this same agregated vision, when there are eservoirs in the powerplant that is connected to 'reservoir', it is accounted for within the Pumped Storage. But when we defined the different variables we wanted them to be also able to host disaggregated hydro. (I think this is why there is 'possibly pumps' in the reservoir and also why the Hydro|Pumped Storage is potentially generated electricity)

Anyway, we must be very cautious in changing the name of any variable which is used in different project as it may have quite a lot of impacts. I would be in favor of keeping Hydro|Pumped Storage (instead of Pumped Hydro) and ensure that all the variables which were generated with Hydro|Pumped Storage in electricity tag will still be generated (which may mean to manually add some), and also that there will not be duplicated variables (but then the validation tests shouldn't work) as eg in power-plant.yaml, some variables related to storage are individually defined for Pumped Storage and Reservoir (as frequired by some models, in particular the power system models )

In summary I don't really care wether Hydro Pumped Storage is seen as a storage techno or an electricity generation techno (because from my point of view of working on power system models it is both), but we need to ensure that all the variable names which the previous way of defining it was 'generating' are still generated , or unused...

Ready to help you checking the variables if needed,
Best

[robertpietzcker]

Hi @sandrinecharousset
do I understand you correctly that it would be fine for you if we add Pumped Hydro to the tag_storage_types.yaml as long as we don't remove it from tag_electricity_input_types.yaml?

This would work for our purpose, as we would have full technology reporting under the "storage" label, while it is not so relevant for us if teams also include pumped hydro under hydro or not - and anyway, I can always ask them to please not include it.

so in this way it would be available for the projects you are working in.

[sandrinecharousset]

Dear @robertpietzcker , we also need to ensure consistency, meaning that we should not have 2 identical variables with different names and we should not generate twice the same variables by using the tag lists (but from what I remember this would result in tests failing). Also there is sth with ensuring consistency in the sub levels of each variables (like Capacity|Electricity|* when summed should give Capacity|Electricity if it is of use to someone...... Maybe @danielhuppmann will have a wider view than I do..... I also include @erikfilias in this discussion as he was one of those very involved in creating the list of variables for the power system (and the model he is working with is also still using the nomenclature for an ongoing project).

Also I found out that we could have had this discussion earlier, had I noticed you had done the change which I had removed in last january (see the history of the file and closed PR #338 .... At that time I thought it was a remaining mistake from our cleaning of the nomenclature..... So we removed 'Pumped Storage' for the following reason: "The comment says 'does not include hydro' but Pumped Storage was still included.... which would create variables such as eg Capacity|Electricity|Pumped hydro while the use of Electricity Input creates Capacity|Electricity|Hydro|Pumped storage ". It was merged before you had time to jump in ..... sorry for that.....

I think that what we could do now is open an issue so that we can share all different opinions and viewpoints?

[erikfilias]

Thank you for including me in this discussion. In Spain, as well as in other regions, we have a variety of hydro technologies, including:

• Run-of-River Hydropower
• Hydropower Reservoir
• Mixed Pumped Storage Hydropower (with both natural inflows and pumped storage)
• Pure Pumped Storage Hydropower (which functions purely as storage, requiring external electricity to pump water).

Given this diversity, I understand the need to make a clear distinction between these technologies. Pure pumped storage, which behaves like a "virtual battery", should indeed be categorised as storage. However, mixed pumped storage, which generates electricity from both pumped water and natural inflows, has characteristics of both storage and generation.

For clarity and to avoid confusion, I also suggest using the full term Hydropower throughout the tags, as we sometimes work with Hydrogen and abbreviating it could lead to misunderstandings.

1. Hydropower|Pumped Storage should remain under the electricity tag to capture technologies that actively produce electricity, especially for models requiring generation data.
2. At the same time, Pumped Hydropower can be included under the storage tag to capture its energy storage function, especially in its pure form.

This approach ensures that we accurately represent all types of hydropower technologies without duplicating variables. It also avoids breaking existing models while accommodating new needs.

I'm happy to help ensure that variable consistency is maintained across tags to avoid issues such as duplicate generation.

And, we can continue the discussion in the open issue #355.

[danielhuppmann]

Chiming in here from a meta-level. The open entrance project is finished, but ECEMF, openmod4africa and other projects continue to use this repository. This creates needs in different directions.

Going forward, I hope that the initiative for a standardized list of variables across IAM and energy systems models at https://github.com/IAMconsortium/common-definitions will provide a solution to some inconsistencies introduced in this repository, and projects may gradually transition to that structure.

In the short-term, I suggest to close this PR and simply add the capacity-addition variables (which are necessary for ECEMF) in a new PR. Alternatively, these variables could be added only to https://github.com/iiasa/ecemf-workflow - practically speaking, ECEMF uses the combination of openentrance plus any variables defined there.

[robertpietzcker]

Thanks for your comment, @danielhuppmann
I agree that if differences remain, this is a useful workaround.
In this specific case, I have the impression that the discussion in #355 is converging to a workable version for now, so I would give it a try by adjusting the current PR and see if I understood the proposal correctly.

if not, I will come back to your proposal and just do a commit to the ecemf-workflow github.

[robertpietzcker]

Dear @sandrinecharousset @erikfilias
To bring this point to a decision, I would be very grateful if you could briefly check if my updated PR is in line with your wishes in the detailed discussion in #355, or if you prefer that I don't make this change (then I would make these changes only to the ECEMF github)

[sandrinecharousset]

Thank you @robertpietzcker for this PR. For the changes in electricity and storage, it fills the requests that I had. We will have 2 variables with the same meaning somehow with the Hydro|Pumped storage in electricity and the Pumped hydro in storage , but this probably is unavoidable (we had eg defined manually some required variables such as Maximum Storage|Electricity|Hydro|Pumped storage as power system models do need this and this was already not generated via one of the tags).
Another minor comment: I see you have added Capacity Addition variables in technology . There existed already -only for electricity- variables such as Commissioned Capacity and Decommissioned Capacity in electricity-expansion.yml. Maybe there is some redundancy here? But I believe that ECEMWF needs those capacity Addition variables....

[erikfilias]

Thank you, @robertpietzcker, for your efforts to address the key points raised in this PR. I apologise for my late response.

On electricity and storage tags:
I agree with @sandrinecharousset that having Hydro|Pumped Storage in the electricity tag and Pumped Hydro in the storage tag may be unavoidable, given the dual functionality of this technology in many models.

On the variables of capacity addition:
I agree with the comment regarding potential redundancy between the newly introduced Capacity Addition variables and the existing Commissioned Capacity and Decommissioned Capacity variables in electricity-expansion.yml. Perhaps there is an opportunity to streamline them alongside the existing variables to avoid a potential overlap.

Thank you again for your work on this PR.

[danielhuppmann]

Looks ok, thanks!