Scenario name as foreign key

[EvaWie]

We liked the idea of defining the scenario name, so that it can be used as foreign key.

Which columns should/could the scenario table have?

• scenario name
• scenario description (ca. 3 sentences)
• scenario year
• weather year
• maybe heat sector assumptions: heat demand reduction factors and district heating share (for Germany)
• ...

Who will implement this table?

[gplssm]

Right now, assumptions are stored decentrally (i.e. district heating share, parameters for NEP). For scenario variations it might be helpful to have some assumptions and parameters stored centrally. This might be relevant for demand data of newly introduced sectors in particular. So please, if you already know that you're data has assumptions that might be interesting for a scenario variation, please add it here. By doing this we get a better overview about this scenario table should look like.

@nesnoj for example the number of BEVs might be a valuable scenario variation, right?

[nesnoj]

@nesnoj for example the number of BEVs might be a valuable scenario variation, right?

Yes, and other params too.
To avoid bloating the columns it may be a good option to store it as json.

[ClaraBuettner]

I added a first draft of the scenario-table on this branch.
I wasn't sure in which schema I should add it (it is a combination of society, demand, supply... data) and preliminary added it to the grid schema (because it will contain information about all datasets and sectors).

The parameters of each sector and scenario should be written in the corresponding dict of parameters.py. If the list of parameters will be too long, we can think of creating separate files for each sector.
I added some example parameters and tested them in the demandregio import 4600423.

[ClaraBuettner]

There is a table to store scenario parameters, so I will close this issue.