GUI/Graphical User Interfaces for people to input data in models

Modelling
, ,
1

Dear OpenModers,

I am working at Reiner Lemoine Institute on the project open_plan, together with Deusche Gesellschaft für Sonnenenergie (DGS) and Postdam Institut for Climate Impact Research (PIK). One of the goal of the project is to build a bridge enabling stakeholders (engineer buros, municipalities, energy consultants) to use open source energy models to plan energy systems.

A key takeaway form a stakeholder workshop we held was the need to have a GUI for users to interact with the models/model frameworks.

The design of GUIs usually quite varies between projects as it has to adapt to different needs. However, I think we should be able to identify a few structural elements which could be generic enough to be used by more that one project (a way to graphically draw a network of energy system components to define an energy system model for example).

GUIs are often quite good for commercial tools because there is money to pay the people working on them. I have the impression that the GUIs are lacking for open source energy models because there is not enough resources explicitly dedicated to them in the research projects.

I think a nice way to overcome that problem would be to work on it together as a community and I was wondering if some of you were willing to share resources/experiences about GUI (or requirements a GUI should fulfill in your opinion).

The modelling framework we are using for open_plan is oemof, but I have up to now forseen a way to make a “GUI blueprint” which could be used for other modelling frameworks.
One thing which would help a lot having a common “GUI blueprint” for energy system modelling would be to define an input/output energy system data format standard, but I’ve seen across the posts in the forum that there is not yet a consensus on that.

I don’t know what is the best way to follow up on this (maybe I stir no interest at all and the question is then settled :slight_smile: ) Maybe a meeting with the persons interested to collaborate/exchange on this and the minutes of the meeting or its summary gets then posted in the thread of the topic?

Looking forward to see what you think about that!

Thank you

Reference from @robbie.morrison hinting that there is not much GUI across energy models/frameworks
Chang, Miguel, Jakob Zink Thellufsen, Behnam Zakeri, Bryn Pickering, Stefan Pfenninger, Henrik Lund, and Poul Alberg Østergaard (15 May 2021). “Trends in tools and approaches for modelling the energy transition”. Applied Energy . 290 : 116731. ISSN 0306-2619. doi:10.1016/j.apenergy.2021.116731. CC‑BY‑NC‑ND‑4.0 license.

1 Like
2

The OSeMOSYS gang recently released this user interface, based on Microsoft Excel and the Access relational database. Access only runs locally, which might be seen as limiting in some use cases?

  • Climate Compatible Growth (ongoing). clicSAND. GitHub.

Another thought is the development of what I describe as “data systems”, more here. A suitable data system might then provide a natural bridge between a GUI and the underlying model framework? Moreover, one GUI could potentially cover several frameworks because these data systems are specifically designed to abstract away some of the framework interface. Spanning several frameworks could then lead to economies of scale in terms of development? HTH, R

3

GUI development is an evergreen topic in the OSeMOSYS “gang”. Many of the projects which use OSeMOSYS have capacity building and pedagogical aims at their core. In these situations a GUI can be very useful to help learners focus on the concepts and not get caught up in learning an arcane algebraic modelling language (or a new programming language) instead of how to model an energy system.

In fact, there is already (prior to clicSAND) a prototype GUI for OSeMOSYS called Momani (source on Github). Unfortunately, this has suffered from lack of maintenance over the years caused by lack of funds/expertise/resources/documentation. There are some aspects to Momani which are quite cool, but others are frustrating, and this has led to a situation where it is frequently used (with much muttering and cursing) but really we’d quite like something else.

There’s a real tension between energy system models as research code, which is often constantly being developed and changed and perhaps never reaches a stable version, and a GUI, which benefits from, and relies upon, a stable interface. This could be managed to some extent through best-practices - use of semantic versioning, good design of interfaces, careful design of the GUI to be general enough to cope with changes to the energy system model framework etc.

I think that lowering ambition, and focussing on the core requirements of learners is what is realistic. However, even these core requirements are not trivial. At a minimum, you want:

  • basic data entry - but data is generally “big” - and manual entry of numbers in cells is painful for anything more than the simplest toy model
  • a button to run the model - deploying locally can also be painful, running in the cloud can be expensive
  • visualisation to view results - needs configuration and setup for each framework, and each model, but lots of scope here to save time and effort; generally everyone loves to customise their plots.

A further challenge is:

  • how to make this community owned, maintained and useful for everyone? Choosing a proven technology may be more effective in terms of community maintenance, but result in a less useable or powerful interface.

I will be interested to see how the project takes this forward, and happy to discuss more.

2 Likes
4

@agnese.beltramo and @Hauke pointed out to me that otoole is also a type of GUI. Using otoole, you can convert across input data formats for OSeMOSYS - between an Excel spreadsheet, where the YEAR dimension is used to present parameters in wide format, a Frictionless datapackage, GNU MathProg datafile or a folder of CSV files. By developing small tools which focus on keeping data mobile and reducing the friction of using one or another format, you open up the possibility for users to develop their own workflow, as well as creating the backend to a future GUI.

5

Hi all,

I’ve used myself Excel based data entry for optimal expansion models, and it is something I do not wish even for my worst enemies. Those Excel “interfaces” are the least resistance path. The maximal resistance path is a good user interface and that is why those are rare.

Making a good GUI is hard because you have to mix functionality, maintainability, allow many functions in one place, be intuitive and look nice. To come up with GridCal’s GUI design took me a while and I still change and update things if I feel that they are not intuitive or they could be simpler to maintain. With the years I’ve come to realize it is always a good decision to simplify things even if it makes the code less obvious (i.e. inheritance, polymorphism, etc…)

The hardest part of GUI design for me is to add new functionality while keeping it clean. For that sometimes you need to add a component and sometimes delete a bunch of components and replace them with something more general.

For communities to do really complicated things like a good GUI, you need to ask yourself about the individual motivations to do so. I’ve always worked in consultancy and now in a TSO, so in my case, if I wanted others to use my stuff instead of forcing me to use crappy excel “tools” I had to make good GUI’s. I believe it is not the same in academic circles where almost everyone can code and prefer things their way, and to add a GUI is not going to make papers more publishable.

Whenever you want the nature to go through a route that is not the least energy one, you need to force it or incentivize it. In my case I just do it my self and incentivize others through that route because once it is done, it brings so much more. This takes way less time than convincing people.

TLDR; If you want a good OSeMOSYS GUI, make it! :wink:

Best regards,
Santiago

6

Some news about GUI for oemof components, it seems that to have one seed planted help other plants to grow ^^ :
The HochSchule Nordhausen, will inspire themselves from the GUI of the open_plan project (open_plan, GitHub - open-plan-tool/gui: Energy Planning Application) to make a gui that allow the user to interact with oemof component in a graphical way (open_plan does some abstraction to ease the experience of less techy users):

On another front, I also use some of my spare time to try enabling the drag and drop interface for pypsa @tom_brown @MaxParzen : a very helpful thing is that the component attrs are already described extensively in .csv file, so I could simply parse them to generate a database model description automatically, from there there is not much efforts to have a similar drag and drop component as in open_plan. The question I still need to figure is how to then combine the information of the DB to instanciate a pypsa network on, say, a simulation server. I wanted to be explicit about this development in case some other people are working on this or interested by my work on it and I found not better place than the openmod forum.

1 Like
7

Very cool @pierre-francois.duc
Is there somewhere a video available?
Just saw that the application in locked behind a registration.

Will you demonstrate the tool at your soonish event on 16th of November 2022?
Registration for the event: https://open-plan-tool.org

8

Yes we will demonstrate the tool at this event, there is no video yet, it is in preparation. The registration is free and easy and there is a usecase one can load directly as a new user (we also want to find a way for people to look at the tool without being logged in, but I am a team of one for backend development and assisted a bit for frontend so I try my best to juggle between all the TODOs ^^)

9

I couldn’t attend today because I was stuck in meetings, unfortunately.
Is there a recording that you can share here?

10

There will be a recording of a demo that will be uploaded to the youtube channel of open_plan, I will post the link once it is uploaded :slight_smile:

1 Like
11

@MaxParzen : hier is the link to the video (in german only, as the stakeholders were Germans): Wärmeplanung mit dem open-plan-tool - YouTube

1 Like
12

@pierre-francois.duc That GUI interface is quite remarkable work. Any chance of adding a new audio track in english or re‑recording the entire demo in english?