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?]
- 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 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, while "primary outputs" will be moved to the model 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.
- 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, when 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 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.
- 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?
MF - openness
for any comments, hints and questions on the categorie "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.
- 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
- 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.
- 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?
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?]
- 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?]
- 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)?
- 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".
MF - Coverage
for any comments, hints and questions on the categorie "coverage"" for the model fact sheets please use this discussion topic
- Is the separation between "Modeled enery sectors" and "Modeled demand sectros" right?
Are there other 'sectors' to include in the options?
[Coverage; ; options; ]
- 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?]
- 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 a check box: "Multiregional model" in the coverage section. Please, make alternative suggestions, if you do not like that solution.
- 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?
MF - Mathematical properties
for any comments, hints and questions on the categorie "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
- 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?
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. )
- 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?
SF - general information
for any comments, hints and questions on the categorie "general information" for the scenario fact sheets please use this discussion topic
SF - Data
for any comments, hints and questions on the categorie "data" for the scenario fact sheets please use this discussion topic
SF - assumptions
for any comments, hints and questions on the categorie "assumptions" for the scenario fact sheets please use this discussion topic
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?
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
FF - references
for any comments, hints and questions on the categorie "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
- APPEARANCE
the appearance is still under construction but you can already mention what you would propose concerning the design.
To start:
* I like the inclusion of the GitHub-Info
* I would prefer to take out the items where not necessary (example: name of the model, abbreviation, logo,...)
