(http://platform.openmod-initiative.org/factsheets)
The link leads you to the proposition of model-, scenario- and framework-factsheets which are still under discussion. The factsheets shall ameliorate the transparency and concerning the scenarios also the reproducibility.
Please feel free to add your comments by using the discussion-site of this wiki page under the topic that you want to comment (e.g.: you want to add something to the categorie "openness" on the model factsheet than please use the topic "MF - openness").
The development was going on on a Google docs before - we included all comments that we didn't consider up to now already on the discussion site.
We will make a conclusion of all comments end of mars, so that we can present and discuss the factsheets at the openmod-meeting in Stockholm before we release them.
Model fact sheets (MF)
(http://platform.openmod-initiative.org/factsheets/models)
Introduction page
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 made 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 led to the model integration fact sheet, which are meant to support the reproducibility of model results. Whereas she/he is led to the discussions about the ways of model integration with regard to more general questions.
General model fact sheets
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.).
The logged-in model developer can open an empty form where he 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:
In contrast to the existing fact sheets in the wiki, websites based on django are able to display contribution data from GitHub. Dear openmod community, please, find a draft for improved fact sheets "here" and give us your feedback to this proposal.
Model integration fact sheets
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 (providing a link)? Is the combined model available?
- 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)
First of all a user sees a list of scenarios, which she/he 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.
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 logs 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. Since a couple of scenarios might belong to one study, they might have some facts in common. Therefore, this information can be copied in order to avoid double work. 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)
Explanations on the concept of frameworks are provided on an introduction page: They are collections of (mostly) 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 do not need to be developed over and over again. Typical functions are for example:
- 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 started 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.
A developer of energy modelling frameworks logs in and fills out the form to publicate her/his framework.
Implementation:
The framework fact sheets will be similar to the model fact sheets, but adjusted to the characteristics of frameworks.
