|
|
| Line 52: |
Line 52: |
| | :::I understand that APIs are to connect with other models abd a GUI is to facilitate working for the user. suggestion: leave it as it is? <span class="userid-0 comment-signature" timestamp="20160418215759">[[Special:Contributions/192.168.42.1|192.168.42.1]] 18 April 2016, 23:57 (CEST)</span> | | :::I understand that APIs are to connect with other models abd a GUI is to facilitate working for the user. suggestion: leave it as it is? <span class="userid-0 comment-signature" timestamp="20160418215759">[[Special:Contributions/192.168.42.1|192.168.42.1]] 18 April 2016, 23:57 (CEST)</span> |
| | ::::Erklärungen ergänzen (ausschreiben) <span class="userid-71 comment-signature" timestamp="20160419140742">[[User:Berit Müller|Berit Müller]] 19 April 2016, 16:07 (CEST)</span> | | ::::Erklärungen ergänzen (ausschreiben) <span class="userid-71 comment-signature" timestamp="20160419140742">[[User:Berit Müller|Berit Müller]] 19 April 2016, 16:07 (CEST)</span> |
| | + | :::::We are working on the implementation. <span class="userid-0 comment-signature" timestamp="20160422104026">[[Special:Contributions/192.168.42.1|192.168.42.1]] 22 April 2016, 12:40 (CEST)</span> |
| | ==MF - Coverage== | | ==MF - Coverage== |
| | for any comments, hints and questions on the categorie "coverage"" for the model fact sheets please use this discussion topic <span class="userid-71 comment-signature" timestamp="20160229144029">[[User:Berit Müller|Berit Müller]] 29 February 2016, 15:40 (CET)</span> | | for any comments, hints and questions on the categorie "coverage"" for the model fact sheets please use this discussion topic <span class="userid-71 comment-signature" timestamp="20160229144029">[[User:Berit Müller|Berit Müller]] 29 February 2016, 15:40 (CET)</span> |
Revision as of 10:40, 22 April 2016
MF - general information
for any comments, hints and questions on the categorie "general information" for the model fact sheets please use this discussion topic
- "Institutions" does not include other Organisations
Alternative suggestion: "Partners"
[General Information; * ;Institution(s); text; ; Which institutions develop(ed) the model?]
ToDo: Change "Institutions" to "Partners" in MF, FF and SF
- I prefer "partners", too; that would also match little bit with Francescos suggestion to include "Partners";
@Francesco: the employment of the model belongs more to the scenario fact sheet or can also be linked to through the categorie "references"; that's why we didn't included it here
- We will rename the "institution(s)" as "partner(s)".
Yes, in this case we are asking for the organisations developing the model. Studies, projects and organisations, that use / employ the model can be named in the section "references".
- What should be considered in the "Primary purpose"?
[General Information; ; Primary purpose; text; ; What is the primary purpose of the model?]
- Is the question regarding the primary purpose of the model unclear?
I would rather ask, whether we additionally need text fields asking for implemented and planned model extensions which go beyond the primary purpose of the model.
- primary pupose and primary output is quite unclear; none of the testers who filled in their model wrote anything there.
there should be examples as the models and their tasks are very different
My personal opinion is that only primary purpose should be in the general information and the output should go to the category "model integration" which is in discussion to be added
- The text field "primary purpose" was added after the first testers filled out the form. Therefore, it was empty. This text field will stay in the general information section. "primary outputs" will stay in the general information section, until we decided, whether frameworks have outputs or not. If the answer is yes, the text field should stay in the general information section of the model- and framework fact sheets, because the framework fact sheet does not have an integration section.
There will be no additional text field for implemented and planned extensions. If they are important, people will mention them in "primary purpose".
Feel free to make alternative suggestions, when you dislike this solution.
- framework: delete primary output
model: leave both in general information
- General Question:
Which other field should be 'required fields' (*)
- as far as I understand it the stars are standing for "required fields" that is not mentioned anywhere - that should be added.
required fields that I would change to "not required":
acronym, documentation quality, number of users, number of developers, model file format, Input/output data file format; Additional software
not required fields that I would change to "required":
Open Source, Modelling software
- "Acronym" will stay a mandatory field, because it is assumed that all models have it and it will be part of the list of all model fact sheets
*documentation quality" stays a mandatory field, because it is a drop-down menu. The option "not available" will be added.
*"Number of users / developers" stay also mandatory fields (drop-down menus). "---" is already an option.
*"Model file format" stays a mandatory field. The option "other" exists can stay empty, if people really do not want to tell the format.
*"Input / output file format" will not be mandatory in future.
*"Additional software" will no longer be a mandatory field.
*"Open Source" is a checkbox, checkboxes never have "*".
*"Modelling software" will not become mandatory.
- I'm not sure if we already discussed it but we didn't note it here anyway: why do you think model file format is mandatory and model software shouldn't be?
- Decision:
model file format: not mandatory
modelling software: mandatory
- I think the question if it is a multi regional model or a mono regional model is very essential and I would put it in the general informations
- There will be added a check box: "Multiregional model" in the coverage section.
- I prefer it in the general information but in coverage would be ok- can we close this with a decision on the 20th april?!
- I would prefer in the mathematical properties section.
- Ok, will be be moved.
- Do we want to invite transportation modellers to fill out model fact sheets for their models on the openmod online presence?
Is the model fact sheet form suitable for transportation models?
- I would like to but I don't know what the openmod community thinks about - shall I try to put the question in Stockholm?
- We will have to open up to different kinds of models. Mobility is part of the energy system. How can we find out the requirements of these models?
- Fact sheets passen so nicht ganz; vielleicht mit einigen Feldern die "other" benennen und dann Platz für weitere Einträge lassen kann das ermöglicht werden
MF - openness
for any comments, hints and questions on the category "openness" for the model fact sheets please use this discussion topic
- Francesco proposed to add the option to say when approximately it may become open source under the item 'planned to open up in the future'
I strongly support that! If this checkbox is clicked there should be a possibility to add a year and/or a month
- We are working on the implementation.
- still missing? Planned to implement?
- Gibt es issue??
- GitHub Issue #49
- the two items "open source" and "source code available" should be put together in the form that, if open source is checked with yes you have a text field to add the link or comment where to get the code
CLOSED - that's implemented as Eva described it
- We will keep the checkbox "source code available", because the souce code of a model might not be available yet. When the check box is ticked, you can tick the "GitHub checkbox" and fill out the text field "Access to source code" with for instance a link.
- This is still missing - right?
- Is the separation between "Modeled energy sectors" and "Modeled demand sectors" right?
Are there other 'sectors' to include in the options?
[Coverage; ; options; ]
- CLOSED
- Francesco:asked why output data access was erased. As it is a critical point.
I guess because it is more part of the scenario fact sheet.
Or is the question where it is put from the model side and in which form?
- output data is not yet mentioned in the fact sheets? we should put that somewhere
- Access to output data doesn't make sense for Models - only for scenarios
MF - Software
for any comments, hints and questions on the categorie "Software" for the model fact sheets please use this discussion topic
- What is the correct name?
Should the version be included? (e.g. Python (3.4))
"Modelling software (Version)" or "Programming language" of the model
(Python, GAMS, C++, Matlab...)
[Software; * ; text; ; What modelling software and which version is used?]
closed
- Modelling software is a better term here because one might use languages, that are no programming languages but still executeable (e.g. BPMN).
Major versions (e.g the first digit) should be included, as a change of this number implies changes that are not upward compatible. But this should be up to the modellers, because it might be missleading. Imagine you wrote a model in C++ that is compatible to C++98 just because you did not use certain newer features for some reason. If you specify your modelling language as C++98 your model might look old and out-of-date. Whilst specifying it as C++14 seems like one is forced to use a C++14 Compiler, which is actually not true.
- Sould there be a seperate field for 'Add-Ons', 'Add-Ins' or 'Packages'?
[software; ; packages/add_ins; text; ; Are there any add-ins for the model, separated from the source code? What are they about? Are they available? Where?]
-> additional software
- I think add-ins should be included. There are explanatiory questions still missing which I think is important to differenciate between "additional software" and "add-ins"
- anybody knows how to delete a comment field once saved (like this one)?
- CLOSED - additional software includes all; you can add as many lines as necessary
- Rename "GUI" to "Interfaces (GUI)"
[software; * ; Interface/GUI; checkbox/text; ; Is a graphical user interface available? / Are there any interfaces? Which? Are they licensed or available? If available, where from?]
- For APIs, please, see also the model fact sheet category "model integration".
- I understand that APIs are to connect with other models abd a GUI is to facilitate working for the user. suggestion: leave it as it is?
- Erklärungen ergänzen (ausschreiben)
- We are working on the implementation.
MF - Coverage
for any comments, hints and questions on the categorie "coverage"" for the model fact sheets please use this discussion topic
- closed
- Include ALL possible options to the "Modeled energy carrier" and "Modeled technologies"?
Is it essential to list all options on the second level?
[coverage; ; Modelled energy carrier (primary energy carrier); options; gas (natural gas, biogas, hydrogen); liquids (petrol, diesel, ethanol); solid (hard coal, lignite, uranium, biomass); other renewables (sun, wind, hydro, geothermal heat); Which energy carrier are modelled?]
CLOSED
- In the fact sheets the headings (the first level) are missing. That is a bug.
How was it meant to look like?
Modelled energy carrier (primary energy carrier)
gas (natural gas, biogas, hydrogen); liquids (petrol, diesel, ethanol); solid (hard coal, lignite, uranium, biomass); other renewables (sun, wind, hydro, geothermal heat)
Modeled technologies: components for generation or conversion
renewables (PV, wind, hydro, biomass, biogas, solar thermal, others); conventional generation (gas, coal, oil, liquid fuels, nuclear); CHP;
What is the problem?
How do we avoid doublings, but make it correct and informative at the same time? For instance petrol, diesel, ethanol are not primary energy carriers, but oil is.
- Where do we put the question if it is a multi regional model or a mono regional model? I think it is very essential and would put it in the general informations
- There will be added the check box "Multi-regional model" in the coverage section. Please, make alternative suggestions, if you do not like that solution.
- math properties.
because it doesn't depend on the region.
- CLOSE - see above (suggestion: methematical properties)
- The point "Network coverage / representation (electrical grid)" with the options AC load flow, DC load flow, Net transfer capacities should stay limited to the electrical grid, but what is the right term to describe the three options?
- suggestion: properties electrical grid
MF - Mathematical properties
for any comments, hints and questions on the category "mathematical properties" for the model fact sheets please use this discussion topic
- At the workshop in Berlin we discussed, whether the model fact sheet should include the main equations of the model. We came to no final conclusion. What is your opinion?
- Hello, in my opinion it should not. If the source of the code is clearly referenced, it is straightforward to go and check. Moreover, in some cases it may be difficult to decide what the main equations are. Don't you think so?
Francesco
- CLOSED - Agreed with Francesco
- in the google sheet the item "model class" were with options. Now it became text - why? if we leave it like that the dicussed options should be in the description to clarify the item.
- There should be options. We discuss them right below this comment in the next discussion point.
- There is a vast number of different types of optimisation problems. You can classify regarding
- solution space (mixed integer, integer, real, ...),
- problem class (linear, non-linear, quadratic),
- objectives (single, multi)
...
Same goes for solution/optimisation algorithms:
- complexity (O(x), ...),
- approximation quality
An enumeration of all optimisation problems might be too complex. Sadly, I do not know which of these are common approaches in energy systems but it might be helpfull, if we state the most important for energy modelling. Any experts here?
- could we put that in the info text of the mathematical model class?
MF - References
for any comments, hints and questions on the categorie "References" for the model fact sheets please use this discussion topic
- Francesco added the question: item 'larger scale usage' in category 'references': I don't get the point, larger than what?
We have to clarify that or take the point out (which I would prefer, I think it referred to the region the model was originally developed for. )
- We suggest renaming "Larger scale usage" as "model usage"; info text: Who uses the model?
Do you agree?
- Yes - Evas suggestion!
- what is meant by the item 'validation' exactly? maybe some examples in the column for the comments may help (added Francesco)
I suggest:
e.g. have the outcomes of the model been revied by peers? did you crosscheck the outcomes with an other model?
- Instead of the text field, we suggest the following options:
* peer-reviewed,
* outcomes cross checked with other models or data
* other + text field
- 1. is the reference peer-revied?
2. is the model validated?
* cross-checked with other models
* checked with measurements (measured data)
3 other
- does the validation refer to the model or the reference?
SF - general information
for any comments, hints and questions on the categorie "general information" for the scenario fact sheets please use this discussion topic
- The "name of the scenario" should be under the general category not below data
- We will rearrange the set-up.
- item: Economic (behavioural) rationale
if more tools/models are used it could be necessary that one have the possibility to put the model in the top and the the check boxes for each model
Erscheinungsbild: on the right side there is a lot of space and the writing is left in too many lines
- Thank you for your comment. We will consider to enable the user to select more than one tool and accordingly its approach.
We are also trying to avoid all these line breaks. The texts are still long. Please, feel free to make suggestions for shorter texts! The text standing in parenthesis could for instance become information text (accessible via the question marks).
- item: technologies included:
others should be at the end
three times heat instead of electricity, gas heat (it should be added that the question is if the grids are included)
- Thank you for this comment. Some things went wrong here. The bug is reported.
The list was meant to look like this:
renewables (PV, wind, hydro, biomass, biogas, solar thermal, others); conventional generation (gas, coal, oil, liquid fuels, nuclear); CHP; networks (electricity, gas, heat); storages (battery, kinetic, CAES, PHS, chemical)
SF - Data
for any comments, hints and questions on the categorie "data" for the scenario fact sheets please use this discussion topic
- The flag data is not there but is called openness....
- That bug will be fixed.
SF - assumptions
for any comments, hints and questions on the categorie "assumptions" for the scenario fact sheets please use this discussion topic
- 1. The differenciation between data and assumptions is not clear
2. the click boxes are not clearly related to the phrases (which belongs where?)
- ad 1. Please, help us to define and differentiate between the terms "data" and "assumptions". So far we understood data as empirical data, taken from statistics or other sources. Assumptions are estimations (own estimations or values taken from other studies).
ad 2. That is true. That issue was reported.
SF - results
for any comments, hints and questions on the categorie "results" for the scenario fact sheets please use this discussion topic
FF - general information
for any comments, hints and questions on the categorie "general information" for the framework fact sheets please use this discussion topic
- Do frameworks have outputs? Or is the point "Primary Outputs" pointless?
- frameworks don't have outputs
- Are there frameworks that are based on frameworks?
- This meta ;)
Assumption: If a Framework is based on another Framework it is either:
1. Part of the Framework
2. An independent Framework
FF - openness
for any comments, hints and questions on the categorie "openness" for the framework factsheets please use this discussion topic
FF - software
for any comments, hints and questions on the categorie "software" for the framework factsheets please use this discussion topic
FF - design and interfaces
for any comments, hints and questions on the categorie "design and interfaces" for the framework factsheets please use this discussion topic
- Should the question "supported model types" (with the options: Grid optimisation, demand simulation, feed-in simulation, other + text field) be moved from "Design and Interfaces" to "Basic information"?
- in my eyes: yes
FF - references
for any comments, hints and questions on the category "references" for the framework factsheets please use this discussion topic
MF - model integration
for any comments, hints and questions regarding the category "model integration" for the model fact sheet
general discussion points
here is the space to put the topics that are not linked to a special sheet or category
- nearly every item should have explanatory questions and/or examples
- What's about links to the Glossary?
- APPEARANCE
the appearance is still under construction but you can already mention what you would propose concerning the design.
To start:
1) I like the inclusion of the GitHub-Info
2) I would prefer to take out the items where not necessary (example: name of the model, abbreviation, logo,...) => CLOSED: Summary: we were dicussing to leave out the points which are not answered in displaying the modelfactsheet. Agains it was the wish to display also what could have been answered. We agreed to display all points.
3) what is the point if the categories are visible or not? I suggest that general informations, Software as well as openness are open while the others are closed (as presetting).
4) It would be nice to have the "primary purpose" (and also the primary outcome) as description under the header; and I think "name" and "acronym" are not necessary to display a second time (already in the header)
5) I would like some colours! green check-mark; red cross
- I do not get your last point. Sorry.
- After additional points it became the second: I closed it due to our discussion
additional idea: the not used points could become grey
