|
|
| Line 6: |
Line 6: |
| | ([http://platform.openmod-initiative.org/factsheets/models http://platform.openmod-initiative.org/factsheets/models]) | | ([http://platform.openmod-initiative.org/factsheets/models http://platform.openmod-initiative.org/factsheets/models]) |
| | | | |
| | + | <br/> |
| | | | |
| | == Introduction page == | | == Introduction page == |
| − |
| |
| − | <u>'''Use Case of all users:'''</u>
| |
| | | | |
| | 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. | | 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: | + | 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) | | *market simulation (models) |
| Line 19: |
Line 18: |
| | *model for the optimisation of flexibility options | | *model for the optimisation of flexibility options |
| | | | |
| − | For detailed model-specific information the user is refereed to the model integration fact sheet, which are meant to support the reproducibility of model results. Whereas she/he is refereed to the [[Discussion: Ways of model integration|discussions about the ways of model integration]] with regard to more general questions. | + | 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 [[Discussion: Ways of model integration|discussions about the ways of model integration]] with regard to more general questions. |
| | | | |
| | + | <br/> |
| | | | |
| | == General model fact sheets == | | == General model fact sheets == |
| − |
| |
| − | <u>'''Use Case of all users:'''</u>
| |
| | | | |
| | 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 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. |
| Line 32: |
Line 30: |
| | 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.). | | 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.). |
| | | | |
| − | <u>'''Use Case of a model developer:'''</u>
| + | 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. |
| − | | + | |
| − | 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. | + | |
| | | | |
| | '''<u>Implementation:</u>''' | | '''<u>Implementation:</u>''' |
| | | | |
| − | 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.
| + | The fact sheets are being changed (as described above) to the next version until march (2016) and will then be shifted from the wiki pages to django based websites with the aim to display additional contribution data from GitHub. |
| | | | |
| | + | <br/> |
| | | | |
| | == Model integration fact sheets == | | == Model integration fact sheets == |
| Line 48: |
Line 45: |
| | | | |
| | *Which APIs does the model have? | | *Which APIs does the model have? |
| − | *With which models has this model been integrated to which model (providing a link)? | + | *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? | | *Which models (providing links) are integrated in the model? How? |
| | | | |
| Line 55: |
Line 52: |
| | Django is used for the implementation. | | Django is used for the implementation. |
| | | | |
| − | | + | <br/> |
| | | | |
| | = Scenario fact sheets = | | = Scenario fact sheets = |
| Line 61: |
Line 58: |
| | ([http://platform.openmod-initiative.org/factsheets/scenarios http://platform.openmod-initiative.org/factsheets/scenarios]) | | ([http://platform.openmod-initiative.org/factsheets/scenarios http://platform.openmod-initiative.org/factsheets/scenarios]) |
| | | | |
| − | <u>'''Use Case of all users:'''</u>
| + | 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. |
| − | | + | |
| − | 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>'''
| |
| | | | |
| | Someone might conclude that a scenario, she/he calculated, is an interesting one because | | Someone might conclude that a scenario, she/he calculated, is an interesting one because |
| Line 75: |
Line 68: |
| | *special assumptions were implemented 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 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. 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. | | 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. |
| Line 83: |
Line 76: |
| | The implementation is similar to the implementation of the model data sheets. | | The implementation is similar to the implementation of the model data sheets. |
| | | | |
| | + | <br/> |
| | | | |
| | = Framework fact sheets = | | = Framework fact sheets = |
| Line 88: |
Line 82: |
| | ([http://platform.openmod-initiative.org/factsheets/frameworks http://platform.openmod-initiative.org/factsheets/frameworks]) | | ([http://platform.openmod-initiative.org/factsheets/frameworks http://platform.openmod-initiative.org/factsheets/frameworks]) |
| | | | |
| − | <u>'''Use Case of model users and model developers:'''</u>
| + | Explanations are provided on introduction page about the concept of frameworks: 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. Examples for functions are: |
| − | | + | |
| − | 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 demand time series |
| | *generating feed-in time series from installed capacities | | *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. | + | 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. | | 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. |
| Line 103: |
Line 95: |
| | 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 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. |
| | | | |
| − | <u>'''Use Case of model developers:'''</u>
| + | A developer of energy modelling frameworks logs in and fills out the form to publicate his/her framework. |
| − | | + | |
| − | A developer of energy modelling frameworks logs in and fills out the form. | + | |
| | | | |
| | <u>'''Implementation:'''</u> | | <u>'''Implementation:'''</u> |
| | | | |
| | The framework fact sheets will be similar to the model fact sheets, but adjusted to the characteristics of frameworks. | | The framework fact sheets will be similar to the model fact sheets, but adjusted to the characteristics of frameworks. |
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:
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.
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.
The fact sheets are being changed (as described above) to the next version until march (2016) and will then be shifted from the wiki pages to django based websites with the aim to display additional contribution data from GitHub.
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.
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
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. 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.
Explanations are provided on introduction page about the concept of frameworks: 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. Examples for functions are:
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 his/her framework.
The framework fact sheets will be similar to the model fact sheets, but adjusted to the characteristics of frameworks.
