Author: Patrik Schönfeldt

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:

Continue reading “Robust Results”

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.

2025.09 dev meeting retrospective

For the last three days, we were meeting at HTW in Berlin for our semi-annual developer meeting. Here are some of the key results:

  • We plan to have an improved lecture/ tutorial session, that might eventually develop into a summer school.
  • There will be a release of oemof.solph mid November. It will include whatever is done until then.
  • Costs calculations in oemof.solph will be aligned with VDI 2067. We plan to distinguish between energy-related costs (€/kWh), capacity related operational costs (€/kW/a), fixed operational costs (€/a) for OPEX and capacity related investment costs (€/kW/a) as well as an investment cost offset (€/a) for CAPEX. At the moment, we group by units, and thus have CAPEX and OPEX mixed.
  • The SubNetworks, we decided to have at the oemof 2025.02 developer meeting are functional, an example is merged in dev.
  • There is a software implementing robust optimisation. We plan to release something along these lines (as rolph).
  • Some of use will create an awareness concept. For upcoming meetings, there will be an awareness team you can contact if you do feel uncomfortable because of other participants or externals. We will also try to organise ourselves so that you can feel save on your trip back to the hotel.

See you next time (in Nordhausen)!

Save the date: oemof user meeting 2026.02

Our next in-person user meeting will take place in Nordhausen from 11th to 13th of February 2026. It will be hosted by Nordhausen University of Applied Sciences partly parallel to the  9th Regenerative Energy Technology Conference (page in German).

We are posting this save the date already, as the parallel RET.Con also allows to submit contributions to its proceedings. If you wish to do so, please send an abstract (maximum two pages A4) to ret@hs-nordhausen.de. The deadline for abstracts to the RET.Con is the 15th of October. If accepted, full papers will be due at the 15th of January. Registration to the oemof track will be possible later, (as usual) without abstracts and proceedings.

Feisty Friday: omeof.solph v0.6.0

Without any public announcement, we shadow-dropped oemof.solph v0.6.0 last Friday (solph package 0.6.0 at PyPI, solph 0.6.0 changelog at GitHub). As yesterday was a public Holiday in Germany, this was an extra-bold move, breaking the dogma “never release on Fridays” in an extreme way. Seems like it wasn’t extra-stupid: Until now, nobody complained.

We decided to do this, as we believe it to be a rather stable release. We have cool new features (time-series aggregation and new result handling), but we marked them as experimental. The most noticeable change probably is the completely revised and reshaped documentation, which we tried to be more beginner-friendly than ever. Other changes include removal of API wrappers that allowed to still use old class names and keywords. Highlights of the release include:

Continue reading “Feisty Friday: omeof.solph v0.6.0”

Demandlib 0.2.2: VDI and BDEW25

If a rough estimate for energy demands is just good enough, standard load profiles can be handy. To easily generate these kinds of profiles, we have the “demandlib” in the oemof cosmos. This week, we released a new iteration that includes profiles as defined by the VDI (Verband Deutscher Ingeneure, Association of German Engineers) and the updated profiles by the BDEW (Bundesverband der Energie- und Wasserwirtschaft, German Association of Energy and Water Industries).

Continue reading “Demandlib 0.2.2: VDI and BDEW25”

2025.02 dev meeting retrospective

At the last developer meeting, in sunny Flensburg, we focused on decision making and drafting for the future development of solph. Here are the main results:

  • There is consensus that we should have common approach of facades or sub-networks. Currently, there are several similar implementations, namely facades in oemof.tabular, nested energy system object (used for cellular approaches, now removed), and node containers (in MTRESS).
  • We worked hands on at the documentation. Improvements will be merged to the v0.6 dev branch. We also have a suggested colour palette to use in examples:
    Lapis Lazuli (#1F567D) , Cambridge blue (#8AA8A1), Pumpkin (#FA8334) , Rose (#FF006E), Icterine (#FFFD77)
  • We drafted a new class Results that will eventually replace the nested dict generated by solph.processing.results().
  • Before thinking about alternative back-ends to Pyomo, we should remove code duplication.
Group picture taken at the balcony of the FH Flensburg building near the habour.

oemof AUA 2025/03 (today)

As announced previously on other channels, we have an “ask us anything” session today. Unfortunately, we currently experience issues with the server that runs our cloud infrastructure, including the calendar. Thus, the link we originally shared is currently unavailable. So, here is a summary: