While we couldn’t hold back ourselves and just announced the upcoming 2027.02 oemof user meeting right when the date was fixed, it is now time to reflect the developer meeting we just had last week.
Recognising the fact that there is a number of packages build upon oemof tools, we started with an overview giving insights into several of them. The idea is that we can move common concepts from the application level to the framework level, lowering the maintenance burden for all of us while offering a more feature-rich base package also for new users. There were
- OpenPlan, a graphical user interface for solph,
- eesyplan, the backend for OpenPlan,
- MTRESS, which evolves from a solph preprocessor to a solph dialect,
- owp-tool, a district heating portfolio optimisation dashboard, and
- heatpumps, a heat pump design dashboard based on TESPy.
Between the former packages, we already knew that usage of sub-nodes, the corresponding post-processing of results and data formats are a shared topic. Consequently, this was one topic to be worked on. In particular, there was a hands-on session on saving results. A second stream was about making solph more accessible. As a result, we now list solvers as an (optional) dependency. This way, you do not have to manually install one. If you want to test this, just install oemof.solph[solver]==0.6.6a1, which implements that change. The naming of “nonconvex”, although confusing, was not changed: We were missing a convincing concept on what to change it to. At last, a redesign of our web page as the most representative entry point was discussed. This included valuable feedback by two first-time attendees.
On a more conceptual level, there was discussion about an abstract maths layer before Pyomo. The background is that approaches like robust and stochastic optimisation currently require either significant rewriting/ copying or low-level model hacks. The idea that this would be worth the time was questioned, however. As a result, we might change to a new language to describe constraints and objective functions provided that it is directly usable (potentially by another solver), increases reusability, and does not take significantly longer to build a model.
Many thanks to the organisers in Bingen and to all participants!