Patrik Schönfeldt

2026.09 dev meeting retrospective

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.

Next oemof user Meeting: Berlin February 2027

Are you an oemof user or simply curious about energy system modelling? Then join us in Berlin in February 2027! What awaits you:

Connect with other oemof users and developers
Join workshops tailored to every level, from your first modelling steps to advanced techniques and problem solving
Present your use case and learn from the projects of others
Get the big picture of the oemof universe and its growing ecosystem of tools
Ask your questions directly to experienced developers
Whether you are building your first energy system model or maintaining a large one – you are welcome.

When? Thursday, 25th of February 2027
Where? Berlin (location TBA)
Registration: oemof user meeting registration form
Latest updates (continuously updated): Meeting page on GitHub

We look forward to seeing you in Berlin!

New HiGHS: oemof.solph v0.6.5

We have just released oemof.solph v0.6.5 (GitHub, Zenodo, PyPI, RTD), which brings not only a number of bug fixes but also support for the solver “HiGHS“. To use it, make sure you have it installed and call model.solve(solver="highs") after you have created the energy system model. The solver can be installed automatically as a dependency without any manual action. (Currently, you need to pip install highspy). Based on feedback we receive in the next time, it might become our new default. So, what is your experience with HiGHS?

Bug fixes and other changes are mostly relevant for users of Flows with a binary status variable (using NonConvex) and TSAM users, but not only:

oemof.network v0.5.3

The release 0.5.3 of oemof.network (GitHub, Zenodo, PyPI, RTD) brings some fixes (mostly concerning subnodes) and two quality of life improvements:

EnergySystem.from_file(filename)

Instead of creating an EnergySystem that is then overwritten based on the file contents, you can now get load a new energy system from a file.

# Deprecated way to load energy system dumps
es_old = EnergySystem()
es_old.restore(dpath="./", filename="es_dump.oemof")

# 0.5.3+ way to load energy system dumps
es_new = EnergySystem.from_file("./es_dump.oemof")

As a plus, you won’t get a warning anymore that your EnergySystem is overwritten. So you have cleaner code and a cleaner output.

EnergySystem.to_networkx()

Registration for 2026.09 dev meeting

As already mentioned at the last user meeting in Nordhausen, our next workshop will be the “2026.09 oemof dev meeting” in Bingen. It will be hosted by the University of Applied Sciences Bingen from the 23rd to 25th of September 2026. If you plan to join, please register using the registration form. (Note: You might not receive an instant reply. Instead, we will answer registrations in batches.)

solph v0.6.4: Saturating Storage

Today, we released oemof.solph v0.6.4 (GitHub, Zenodo, PyPI, RTD). This new version updates the documentation to prefer solph.Results over solph.processing.results(model). Also, the former is automatically returned by model.solve(). This way it is now impossible to accidentally look for results of a model that has not been solved. You can have a look a commit that impressively shows the improvement: 898b457f@GitHub.

Two panels showing battery charging graphs. Left: Constant power inflow and a linear increase of the SOC. Right: Charging power decreases with the SOC. — The new parameters SOC-dependent charging power make it easy to model batteries more realistically.

But there is also a notable new feature: There is now an API to easily set up SOC-dependent charging power. Before, we had an example showing how to formulate custom Pyomo constraints to do the same thing. Please have a look at the SOC dependent charging example for reference. (As the feature just slipped in, the example is not part of the documentation, yet. Also, we highly appreciate feedback for improved generic argument names.)

Working with solph.Results

With the update of solph v0.6.2, we marked solph.Results as stable. As it is planned to completely replace solph.processing.results(model), I am currently replacing all references to the old module from the documentation, so that new users will learn the new feature instead of the one that is about to be replaced.

With the old nested dict structure, we had the very convenient helper solph.views.node(results, "node_label"), which extracted all information related to a particular Node. For example, you could use it to extract all flows from and to a node.

solph v0.6.3: The 2026.02 user meeting retrospective release

Last week, some of us were in Nordhausen (Thuringia) visiting both, the oemof user meeting and the parallel RET.con. As the latter is addressing a broader audience, we tried to also shape the user meeting to welcome novices and interested students.

As an artefact of this meeting, we just released solph v0.6.3 (GitHub, Zenodo, PyPI), that just implements some quality of life improvements. (Tutorial sessions can be a great opportunity to learn about unnecessary barriers that nobody ever reports.)

The parameter nominal_capacity now has an input validation. (We have seen people putting time series, which is currently not supported.)
Argument infer_last_interval of the EnergySystem now tries to infer the interval also if DatetimeIndex.freq is not explicitly set. This simplifies using time indexes from input data.
We added a tutorial focusing on time indexes and aggregation. (Note that some of the described features are experimental and subject to planned changes.)
You can now access results using Results.get(key, default). This way, the Results object is more similar to a dict. We believe it to be easier to use this way.

Another result of the meeting is a new task interest group that will work on saving/loading energy systems and results. The aim is to simplify exchange of data without passing around Python scripts to be able to reproduce insights and findings.

PS: It was mentioned in the local news (nnz-online.de, in German), that we promote transparency and openness in energy research. nice to hear that these topics are recognised to be relevant for the general public.

Robust Results

Just some minutes ago, oemof.solph v0.6.2 (codenamed “robust results”) has landed (GitHub, Zenodo, PyPI). It is no surprise that one focus of this release is the Results object. It is now in a status which we consider stable for productive use. At the same time, we also fixed the old processing.results, which is still handy e.g. when using TSAM, to work with Pandas 3.x.

We recommend to also update oemof.network. Today’s release v0.5.2 (GitHub, Zenodo, PyPI) allows to compare Nodes and their string representations. This sounds rather technical but is a real game changer when analysing results. Consider the following:

Release of “Fractal Fun”

Over the past months, we worked on methods to allow adding more structure to energy system models: It should be simpler to group Nodes (such as Sources or Converters). There are several things that benefit from this, for example cellular models or models spanning several geographical regions. Also, there were several implementations building on top of solph that aimed for this very same thing.

So, with oemof.network v0.5.1 (Github, PyPI, Zenodo) and oemof.solph v0.6.1 (GitHub, PyPI, Zenodo) every Node can now have parent nodes and contain sub-nodes. As both can be added after creation, we codenamed the releases “fractal fun”. When using the new function subnode(class_, local_name, ..) (see documentation) to create new Nodes, labels are automatically created that represent the hierarchy.

Helpers for result processing are currently being implemented. A graph visualisation in oemof.visio has already been implemented and is available as a packaged pre-release (GirHub, PyPI). For a brief code example producing the illustrative figures used here, see oemof.visio:examples/oemof_model_subnetworks.py.

Author: Patrik Schönfeldt