Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed restructuring of file structure #29

Open
danielhuppmann opened this issue May 13, 2020 · 5 comments
Open

Proposed restructuring of file structure #29

danielhuppmann opened this issue May 13, 2020 · 5 comments
Labels
structure Definition of the repository structure

Comments

@danielhuppmann
Copy link
Member

The list of variables is already becoming quite long, causing a risk of confusion or duplication going forward. One option is to separate the definitions into two parts at least for those variables.

Using the following example Capacity|Electricity|Coal|w/ CCS

  • the "variable" of interest: Capacity|Electricity
  • the types of power plants: Coal|w/ CCS

This could then be defined in two separate files and linked by defining the variable as:
Capacity|Electricity|<Power Plants>
and a list of power plants types.

The advantage is that it would result in shorter files. The disadvantage is that it makes reading the yaml files more complicated (because a user would have to switch back and forth), and it would require a more sophisticated programmatic implementation (e.g., a Python package) to use the definitions in automated workflows.

@danielhuppmann danielhuppmann added the structure Definition of the repository structure label May 13, 2020
@danielhuppmann
Copy link
Member Author

@erikfilias @sandrinecharousset any comments?

@philipphaertel
Copy link

This does make sense from our model's point of view, and we do not see a problem in handling the extra yaml files.

As capacities of <Power Plants> are only part of the electricity sector for many long-term energy system models, other placeholder types could be something along the lines of <(Electricity) Storage>, <Heat Cooling Applications>, and <Transport Applications>.

Possible variable combination could then be:

  • Linking Capacity|Electricity|<Electricity Storage> with e.g. Battery|Lithium-Ion
  • Linking Capacity|Electricity|<Heat Cooling Applications> with e.g. Heat Pump|Air-Source
  • Linking Capacity|Electricity|<Transport Applications> with e.g. Electric Vehicle|BEV (although electric vehicle units might need a storage capacity rather than a charging capacity value)

@erikfilias
Copy link
Collaborator

I agree because internally I made a similar process to convert data format.

I only have a doubt related to the validation process.
Is it could be computationally expensive, no?
I imagine that for each variable will have a loop in order to link the variable with all possible options in <Power Plants> and index/match it with their similar in the CSV file.

@sandrinecharousset
Copy link
Collaborator

I also agree with your proposal @danielhuppmann
Moreover, the list of plant types should not be closed and it will be much easier to add a new type of plant with such a strucutre

@sandrinecharousset
Copy link
Collaborator

But I am not completely sure that all kinds of power plant would have the same 'strucure' of 'characteristics'; eg hydro plants are very different.... We usually have 4 different kinds: 1/ thermal plants (including coal, gas, nuclear, biomasse ...) 2/ hydro reservoir plants 3/ other renewable plants with variable capacity (including PV, wind, runofriver) - Those different kinds of plants share some characteristics (like Maximum Active power....) but some characteristics are only for some of the plants (like volumes...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
structure Definition of the repository structure
Projects
None yet
Development

No branches or pull requests

4 participants