Talk:Fact sheets for models, frameworks and scenarios

Revision as of 21:02, 21 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

192.168.42.1 29 February 2016, 15:35 (CET)

"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

Ludwig Schneider 1 March 2016, 11:40 (CET)

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

192.168.42.1 4 March 2016, 08:45 (CET)

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".

Eva Wiechers 18 March 2016, 11:43 (CET)

What should be considered in the "Primary purpose"?
[General Information; ; Primary purpose; text; ; What is the primary purpose of the model?]

Ludwig Schneider 1 March 2016, 11:43 (CET)

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.

Eva Wiechers 2 March 2016, 13:51 (CET)

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

Berit Müller 4 March 2016, 09:55 (CET)

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.

Eva Wiechers 18 March 2016, 13:39 (CET)

framework: delete primary output
model: leave both in general information

Berit Müller 19 April 2016, 15:28 (CEST)

General Question:
Which other field should be 'required fields' (*)

Ludwig Schneider 1 March 2016, 11:44 (CET)

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

Berit Müller 4 March 2016, 10:19 (CET)

"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.
Eva Wiechers 18 March 2016, 14:10 (CET)

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?

Berit Müller 19 April 2016, 14:44 (CEST)

Decision:
model file format: not mandatory
modelling software: mandatory

Eva Wiechers 21 April 2016, 22:58 (CEST)

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

Berit Müller 4 March 2016, 10:29 (CET)

There will be added a check box: "Multiregional model" in the coverage section.

Eva Wiechers 18 March 2016, 14:11 (CET)

I prefer it in the general information but in coverage would be ok- can we close this with a decision on the 20th april?!

192.168.42.1 18 April 2016, 23:38 (CEST)

I would prefer in the mathematical properties section.

Ludwig Schneider 19 April 2016, 11:32 (CEST)

Ok, will be be moved.

Eva Wiechers 21 April 2016, 22:59 (CEST)

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?

Eva Wiechers 10 March 2016, 17:56 (CET)

I would like to but I don't know what the openmod community thinks about - shall I try to put the question in Stockholm?

192.168.42.1 18 April 2016, 23:42 (CEST)

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?

Ludwig Schneider 19 April 2016, 11:36 (CEST)

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

Berit Müller 19 April 2016, 15:43 (CEST)

MF - openness

for any comments, hints and questions on the category "openness" for the model fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:39 (CET)

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

Berit Müller 4 March 2016, 08:51 (CET)

We are working on the implementation.

Eva Wiechers 18 March 2016, 14:51 (CET)

still missing? Planned to implement?

192.168.42.1 18 April 2016, 23:47 (CEST)

Gibt es issue??

Berit Müller 19 April 2016, 15:45 (CEST)

GitHub Issue #49

Eva Wiechers 21 April 2016, 23:02 (CEST)

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

Berit Müller 4 March 2016, 09:39 (CET)

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.

Eva Wiechers 18 March 2016, 15:26 (CET)

This is still missing - right?

192.168.42.1 18 April 2016, 23:46 (CEST)

Is the separation between "Modeled energy sectors" and "Modeled demand sectors" right?

Are there other 'sectors' to include in the options?
[Coverage; ; options; ]

Ludwig Schneider 19 April 2016, 12:25 (CEST)

CLOSED

Berit Müller 19 April 2016, 15:47 (CEST)

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?

Berit Müller 4 March 2016, 17:04 (CET)

output data is not yet mentioned in the fact sheets? we should put that somewhere

Berit Müller 19 April 2016, 00:07 (CEST)

Access to output data doesn't make sense for Models - only for scenarios

Berit Müller 19 April 2016, 15:50 (CEST)

MF - Software

for any comments, hints and questions on the categorie "Software" for the model fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:39 (CET)

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

Ludwig Schneider 1 March 2016, 11:46 (CET)

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.

Martin Glauer 18 March 2016, 16:04 (CET)

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

Ludwig Schneider 1 March 2016, 11:48 (CET)

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"

Berit Müller 4 March 2016, 09:03 (CET)

anybody knows how to delete a comment field once saved (like this one)?

Berit Müller 4 March 2016, 09:04 (CET)

CLOSED - additional software includes all; you can add as many lines as necessary

Berit Müller 19 April 2016, 16:01 (CEST)

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?]

Ludwig Schneider 1 March 2016, 11:49 (CET)

For APIs, please, see also the model fact sheet category "model integration".

Eva Wiechers 2 March 2016, 14:02 (CET)

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?

192.168.42.1 18 April 2016, 23:57 (CEST)

Erklärungen ergänzen (ausschreiben)

Berit Müller 19 April 2016, 16:07 (CEST)

MF - Coverage

for any comments, hints and questions on the categorie "coverage"" for the model fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:40 (CET)

closed

Ludwig Schneider 1 March 2016, 11:50 (CET)

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

Ludwig Schneider 1 March 2016, 11:53 (CET)

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.

Eva Wiechers 18 March 2016, 16:06 (CET)

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

Berit Müller 4 March 2016, 10:25 (CET)

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.

Eva Wiechers 18 March 2016, 14:26 (CET)

math properties.
because it doesn't depend on the region.

Ludwig Schneider 19 April 2016, 16:13 (CEST)

CLOSE - see above (suggestion: methematical properties)

Berit Müller 19 April 2016, 16:17 (CEST)

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?

Eva Wiechers 18 March 2016, 15:32 (CET)

suggestion: properties electrical grid

Berit Müller 19 April 2016, 16:19 (CEST)

MF - Mathematical properties

for any comments, hints and questions on the category "mathematical properties" for the model fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:41 (CET)

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?

Eva Wiechers 2 March 2016, 14:27 (CET)

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

192.168.42.1 7 March 2016, 09:12 (CET)

CLOSED - Agreed with Francesco

Berit Müller 19 April 2016, 16:20 (CEST)

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.

192.168.42.1 4 March 2016, 16:41 (CET)

There should be options. We discuss them right below this comment in the next discussion point.

Eva Wiechers 18 March 2016, 14:44 (CET)

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?

Martin Glauer 14 March 2016, 14:38 (CET)

could we put that in the info text of the mathematical model class?

Berit Müller 19 April 2016, 16:26 (CEST)

MF - References

for any comments, hints and questions on the categorie "References" for the model fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:41 (CET)

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. )

Berit Müller 4 March 2016, 16:46 (CET)

We suggest renaming "Larger scale usage" as "model usage"; info text: Who uses the model?
Do you agree?

Eva Wiechers 18 March 2016, 16:41 (CET)

Yes - Evas suggestion!

Berit Müller 19 April 2016, 16:36 (CEST)

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?

Berit Müller 4 March 2016, 16:56 (CET)

Instead of the text field, we suggest the following options:
* peer-reviewed,
* outcomes cross checked with other models or data
* other + text field

Eva Wiechers 18 March 2016, 16:42 (CET)

1. is the reference peer-revied?
2. is the model validated?
* cross-checked with other models
* checked with measurements (measured data)
3 other

Ludwig Schneider 19 April 2016, 12:32 (CEST)

does the validation refer to the model or the reference?

Ludwig Schneider 19 April 2016, 16:36 (CEST)

SF - general information

for any comments, hints and questions on the categorie "general information" for the scenario fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:42 (CET)

The "name of the scenario" should be under the general category not below data

192.168.42.1 21 March 2016, 14:51 (CET)

We will rearrange the set-up.

Eva Wiechers 7 April 2016, 15:13 (CEST)

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

192.168.42.1 7 April 2016, 09:15 (CEST)

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).

Eva Wiechers 7 April 2016, 15:30 (CEST)

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)

192.168.42.1 7 April 2016, 09:22 (CEST)

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)

Eva Wiechers 7 April 2016, 15:36 (CEST)

SF - Data

for any comments, hints and questions on the categorie "data" for the scenario fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:43 (CET)

The flag data is not there but is called openness....

192.168.42.1 21 March 2016, 14:45 (CET)

That bug will be fixed.

192.168.42.1 7 April 2016, 14:13 (CEST)

SF - assumptions

for any comments, hints and questions on the categorie "assumptions" for the scenario fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:44 (CET)

1. The differenciation between data and assumptions is not clear
2. the click boxes are not clearly related to the phrases (which belongs where?)

192.168.42.1 21 March 2016, 14:56 (CET)

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.

Eva Wiechers 7 April 2016, 16:00 (CEST)

SF - results

for any comments, hints and questions on the categorie "results" for the scenario fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:45 (CET)

FF - general information

for any comments, hints and questions on the categorie "general information" for the framework fact sheets please use this discussion topic

Berit Müller 29 February 2016, 15:52 (CET)

Do frameworks have outputs? Or is the point "Primary Outputs" pointless?

Eva Wiechers 14 March 2016, 11:22 (CET)

frameworks don't have outputs

Ludwig Schneider 19 April 2016, 16:45 (CEST)

Are there frameworks that are based on frameworks?

Eva Wiechers 18 March 2016, 16:49 (CET)

This meta ;)
Assumption: If a Framework is based on another Framework it is either:
1. Part of the Framework
2. An independent Framework

Ludwig Schneider 19 April 2016, 12:59 (CEST)

FF - openness

for any comments, hints and questions on the categorie "openness" for the framework factsheets please use this discussion topic

Berit Müller 29 February 2016, 15:53 (CET)

FF - software

for any comments, hints and questions on the categorie "software" for the framework factsheets please use this discussion topic

Berit Müller 29 February 2016, 15:56 (CET)

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

Berit Müller 29 February 2016, 15:56 (CET)

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"?

Eva Wiechers 18 March 2016, 16:56 (CET)

in my eyes: yes

Berit Müller 19 April 2016, 00:16 (CEST)

FF - references

for any comments, hints and questions on the category "references" for the framework factsheets please use this discussion topic

Berit Müller 29 February 2016, 15:57 (CET)

MF - model integration

for any comments, hints and questions regarding the category "model integration" for the model fact sheet

Eva Wiechers 2 March 2016, 13:58 (CET)

general discussion points

here is the space to put the topics that are not linked to a special sheet or category

Berit Müller 4 March 2016, 10:31 (CET)

nearly every item should have explanatory questions and/or examples

Berit Müller 4 March 2016, 10:32 (CET)

What's about links to the Glossary?

Ludwig Schneider 19 April 2016, 13:16 (CEST)

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

Berit Müller 4 March 2016, 17:49 (CET)

I do not get your last point. Sorry.

Eva Wiechers 18 March 2016, 16:47 (CET)

After additional points it became the second: I closed it due to our discussion
additional idea: the not used points could become grey

Berit Müller 19 April 2016, 11:04 (CEST)

@@ Line 31: / Line 31: @@
 :::still missing? Planned to implement? <span class="userid-0 comment-signature" timestamp="20160418214750">[[Special:Contributions/192.168.42.1|192.168.42.1]] 18 April 2016, 23:47 (CEST)</span>
 ::::Gibt es issue?? <span class="userid-71 comment-signature" timestamp="20160419134500">[[User:Berit Müller|Berit Müller]]  19 April 2016, 15:45 (CEST)</span>
+:::::GitHub Issue #49 <span class="userid-224 comment-signature" timestamp="20160421210225">[[User:Eva Wiechers|Eva Wiechers]]  21 April 2016, 23:02 (CEST)</span>
 :the two items "open source" and "source code available" should be put together in the form that, if&nbsp; open source is checked with yes you have a text field to add the link or comment where to get the code<br/>CLOSED - that's implemented as Eva described it<span class="userid-71 comment-signature" timestamp="20160304083932">[[User:Berit Müller|Berit Müller]]   4 March 2016, 09:39 (CET)</span>
 ::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. <span class="userid-224 comment-signature" timestamp="20160318142647">[[User:Eva Wiechers|Eva Wiechers]]  18 March 2016, 15:26 (CET)</span>

About

Help

Search

Navigation

Search

Interaction

Toolbox

Namespaces

Variants

Views

Actions

Talk:Fact sheets for models, frameworks and scenarios

Revision as of 21:02, 21 April 2016

MF - general information

MF - openness

MF - Software

MF - Coverage

MF - Mathematical properties

MF - References

SF - general information

SF - Data

SF - assumptions

SF - results

FF - general information

FF - openness

FF - software

FF - design and interfaces

FF - references

MF - model integration

general discussion points

Log in / create account

About

Help

Search

Navigation

Search

Interaction

Toolbox

Namespaces

Variants

Views

Actions

Talk:Fact sheets for models, frameworks and scenarios

Revision as of 21:02, 21 April 2016

MF - general information

MF - openness

MF - Software

MF - Coverage

MF - Mathematical properties

MF - References

SF - general information

SF - Data

SF - assumptions

SF - results

FF - general information

FF - openness

FF - software

FF - design and interfaces

FF - references

MF - model integration

general discussion points