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.

Continue reading “Working with solph.Results”

Join the TESPy user meeting in April

From April 13 to 15 the 2nd TESPy user meeting will be held at the Technical University of Brunswick. You are invited to join us to network and exchange with the community, bring your questions to get help in hands-on tutorials and contribute to the development with your feedback, ideas and discussions. Please register here: https://cloud.oemof.org/apps/forms/s/KGPbPMQQJdeCRkmsEsi86Ezq

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”

Join the upcoming oemof meetings

In just a bit more than a month the next oemof user meeting takes place in Nordhausen parallel to the RET.Con conference. From February 11 to 13 you can join us. You will have the chance to exchange with other oemof users and developers, learn something new in the tutorials and also connect with the participants of the RET.Con. Also, the general assembly of the oemof association will be held at the event. For registration and agenda details check out the wiki page on github: https://github.com/oemof/oemof/wiki/Meeting-2026.02

Two months later the second TESPy meeting will be hosted at the TU Braunschweig from April 13 to 15. We plan some tutorials and many hackathons to work on a couple of open issues and potential new features. Get all the information here: https://github.com/oemof/oemof/wiki/Meeting-2026.04%3A-tespy-user-meeting

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.10 first ever TESPy community meeting

TESPy has been part of the oemof organization for about eight years. While it has always been represented at the meetings, it was time for the first ever TESPy community meeting!

Last week around ten of us got together at the University of Applied Sciences in Flensburg to discuss where TESPy is headed and how we can make open source thermodynamics even better. The discussions covered a broad range of topics:

  • A review of the most recent feature additions
  • Beginner tutorials
  • Debugging with tespy version 0.9
  • Custom equations into your model
  • Implementation of new components
  • Showcases of how the software is used
  • Strategies for the operation of large scale heat pumps

During the hackathon an addition to a component was not only drafted on paper but actually implemented in the framework. And, it has already
made it to the latest release of TESPy.

It was really inspiring to meet others working with the software, exchange ideas, and see how the community is growing. Thanks to everyone who took their time to come to Flensburg to join the meeting.


Looking forward to the next one!

Exploring the role of green hydrogen for distributed energy access planning towards net-zero emissions in Nigeria

Nigeria’s power system still relies heavily on captive diesel and petrol generators, with sizeable suppressed and unmet demand. The study by Shari et al. takes this reality as the starting point and uses the Open Energy Modelling Framework (oemof) to ask a question: given Nigeria’s 2060 net-zero target, how and where does green hydrogen make sense once you optimise the system transparently?
The model is implemented with oemof-solph as a cost-minimising linear optimisation. The energy system is represented in oemof’s graph structure which uses buses for carriers and components connected by flows. Electricity and hydrogen each have dedicated buses. Supply components include gas turbines and diesel sets alongside solar PV, onshore wind, hydropower and biomass. The hydrogen chain is modelled with standard solph components: an electrolyser transformer converts surplus electricity to hydrogen, a hydrogen storage component holds the gas, and a fuel-cell transformer reconverts it to electricity when needed. Batteries provide a parallel short-term storage route. Demand, exports and curtailment are represented as sinks. Figures in the paper show the reference energy system and a simplified green-hydrogen chain built exactly this way.

Continue reading “Exploring the role of green hydrogen for distributed energy access planning towards net-zero emissions in Nigeria”

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