|
|
Line 52: |
Line 52: |
| | | |
| Django is used for the implementation. | | Django is used for the implementation. |
| + | |
| | | |
| | | |
Line 62: |
Line 63: |
| First of all a user sees a list of scenarios, which the user can sort by different aspects (e.g. author, time frame, energy system model used, etc.). Clicking on the name of the scenario the user gets to the selected scenario fact sheet including information regarding the origin, the method as well as the used data, data sources and assumptions of the scenario. | | First of all a user sees a list of scenarios, which the user can sort by different aspects (e.g. author, time frame, energy system model used, etc.). Clicking on the name of the scenario the user gets to the selected scenario fact sheet including information regarding the origin, the method as well as the used data, data sources and assumptions of the scenario. |
| | | |
− | The structure and the elements of the scenario fact sheet are currently developed in a [[(https://docs.google.com/spreadsheets/d/1vAYEIqhf4 q4mZ7J2KomSCfOTDsb0mHozxK-LT0FQjU/edit?usp=sharing|GoogleTable]]. | + | The structure and the elements of the scenario fact sheet are currently developed in a [https://docs.google.com/spreadsheets/d/1vAYEIqhf4_q4mZ7J2KomSCfOTDsb0mHozxK-LT0FQjU/edit?usp=sharing GoogleTable]. |
| | | |
| '''<u>Use Case of model developers and model users:</u>''' | | '''<u>Use Case of model developers and model users:</u>''' |
Revision as of 21:53, 8 February 2016
(http://platform.openmod-initiative.org/factsheets)
Model fact sheets
(http://platform.openmod-initiative.org/factsheets/models)
Introduction page
Use Case of all users:
The front page gives the user an overview of all energy system models (meaning executable programmes in contrast to data models) for which a model fact sheet is available. The models might be grouped regarding relevant topics (tags). From here the user can access the model fact sheets of the listed open source and proprietary models.
This introduction page also informs about the fact that models can be make up from a combination of different models to display more complex systems. Interesting aspects / models to combine might be:
- market simulation (models)
- load flow calculations
- model for the optimisation of flexibility options
For detailed model-specific information the user is refereed to the model integration fact sheet. Whereas she/he is refereed to the discussions about the ways of model integration with regard to more general questions.
General model fact sheets
Use Case of all users:
The fact sheets of open source and proprietary models are structured alike and inform the reader about the most important aspects of the model. These two types are differentiated by the symbols used to indicate open source models and proprietary models respectively.
The structure and the elements of the model fact sheet are currently developed in a GoogleTable.
Additionally, for open source models the user gets the link to the source code (which is e.g. provided on GitHub) as well as, if existing, information about the activities, happening on the GitHub (like for example last commit, distribution of the commits during the last year etc.).
Use Case of a model developer:
The logged-in model developer opens an empty form and fills out the text fields, ticks options and selects in drop-down menus in order to create a new model fact sheet. Fact sheets can afterwards be corrected and updated by this or any other logged-in user.
Implementation:
Instead of the fact sheets on wiki pages as before new designed websites being able to display contribution data from GitHub are suggested. Django is used for the implementation.
Model integration fact sheets
Use Case of all users:
In addition to the general model fact sheet in the tab next to the model fact sheet tab the user finds information about the integration of the model.
- Which APIs does the model have?
- With which models has this model been integrated to which model (providing a link)?
- Which models (providing links) are integrated in the model? How?
Implementation:
Django is used for the implementation.
Scenario fact sheets
(http://platform.openmod-initiative.org/factsheets/scenarios)
Use Case of all users:
First of all a user sees a list of scenarios, which the user can sort by different aspects (e.g. author, time frame, energy system model used, etc.). Clicking on the name of the scenario the user gets to the selected scenario fact sheet including information regarding the origin, the method as well as the used data, data sources and assumptions of the scenario.
The structure and the elements of the scenario fact sheet are currently developed in a GoogleTable.
Use Case of model developers and model users:
Someone might conclude that a scenario, she/he calculated, is an interesting one because
- the results differ from what was simulated before or
- it was used for policy advice or
- special assumptions were implemented or…
In that case she/he loges in and creates a new scenario fact sheet by filling out the form provided for scenario fact sheets which contains text fields, options and drop-down menus. Fact sheets can afterwards be corrected and updated by this or any other logged-in user.
In the best case the user not only names her/his data sources but also uploads her/his (data,) assumptions and results into the database.
Implementation:
The implementation is similar to the implementation of the model data sheets.
Framework fact sheets
(http://platform.openmod-initiative.org/factsheets/frameworks)
Use Case of model users and model developers:
The user learns from the provided explanations on introduction page about the concept of frameworks: They are collections of collaborative developed open source programme components / functions. These are used to build models (so called apps) from. In this way double work is avoided, since typical functions, used in energy system models (like the following two examples), do not need to be developed over and over again.
- generating demand time series
- generating feed-in time series from installed capacities
Additionally, mistakes are eliminated, because different model developer and users work with the code and can report bugs and help debugging. Besides, extension or modification can be developed. A framework comes not only with functions (e.g. in terms of class libraries), but also with user and developer rules. One example for a framework is oemof, the open energy modelling framework developed by RLI, ZNES and the University of Magdeburg.
Moreover, on the introduction page the user find a list of frameworks, that can be used to build energy system models. With a click on the name she/he gets to the framework fact sheet, giving an overview of the selected framework.
The structure and the elements of the framework fact sheet are currently developed in a GoogleTable.
A model developer gets an overview of the frameworks in order to decide, whether she/he wants to use one of them. But also a model user, who wants to understand the underlying framework of a certain model, gets an overview looking at the framework fact sheet.
Use Case of model developers:
A developer of energy modelling frameworks logs in and fills out the form.
Implementation:
The framework fact sheets will be similar to the model fact sheets, but adjusted to the characteristics of frameworks.