solph

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:

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.

Interactive solph graph using Dash

Modelling energy systems as graphs, as we do it for oemof, is a rather clear approach. It can help understanding energy flows and the overall network structure. However, in highly complex systems keeping of all the components track becomes increasingly difficult. To tackle this, Tobias Hörter and Andreas Wunsch from Fraunhofer IOSB have created an interactive plotting tool.

The example can be found as a Snippet at the Faunhofer GitLab. The code enables visualization of the system and representation of the component’s parameters upon the model-creation. They use a combination of NetworkX and Plotly DASH Cytoscape for this purpose. The parameters of the model components are first extracted and a NetworkX model is created from the solph energy system afterwards. This network is then used to make cytoscape elements, which are necessary to enable DASH-Plotly to visualize the network.

When running the Dash-App, the user can rearrange the system via drag and drop. Additionally, when clicking on the system components, the parameters of the respective component are displayed. Do you like this approach? How do you draw the energy system graph if you need it?

New solph release: v0.5.4

We released two new versions of solph. One is a stable maintenance release (solph 0.5.4 at PyPI, solph v0.5.4 at GitHub), the other is a packaged preview for the next release (solph 0.6.0a1 at PyPI). In the actual release features the following changes:

Consistency
- Allow sinks/sources to have multiple inputs/outputs
- Allow lower limit for generic_integral_limit
Fixes
- Display inline math correctly and hint towards the usage of the inbuilt slope and offset calculation methods (OffsetConverter)
- Adapt to new Pandas API and fix warnings
- Formulate full_load_time docstring specific for energy
Improvements “under the hood”
- Introduce variable for storage losses
- Replace _Sequence by _FakeSequence

We decided to have an alpha version packaged as well, which mostly changes the way storage_costs are considered. Before, we took into account every time step, which eventually leads to double weighting of the initial/last time step if the storage is balanced (i.e. first and last time step are the same). As the previous implementation wasn’t really broken in all cases, the new way is not strictly a fix. And as it will lead to different results compared to the previous implementation, the change shouldn’t be part of the v0.5 release. So, if you want to consider storage costs, this release is just for you.

Solph v0.5.3 has landed

Today, we released a new version of solph (solph 0.5.3 at PyPI, solph v0.5.3 at GitHub). It adds one important feature, the OffsetConverter now allows multiple inputs and multiple outputs. Still, it is mostly a maintenance release. As discussed in my thoughts on software maintenance, we are currently changing stuff “under the hood” to prepare for future changes. The decision to have a release was because we wanted to make sure that new installations do not have problems due to incompatible dependencies. As the latest versions of Pyomo and numpy are currently incompatible, we skipped a beta release. So in case you experience issues, please speak up.

Details on the new OffsetConverter can be found in the documentation. The component makes it possible to create a Converter with efficiencies depending on the part load condition. With the new formulation, the Flow with the NonConvex property is taken as reference, all other Flows are constrained with respect to this one. For consistence with “normal” Converters, the proportionality factor is called conversion_factor, while the offset to model part-load efficiencies is expressed as a normed_offset to facilitate investment optimisation.

Thoughts on Software Maintenance

Many projects focus on adding features, often neglecting measures to maintain software quality. One reason for this is financing, may it because new features can sell new licenses or because project funding is connected with them. On the long run, of course, easy-to-maintain code also facilitates adding new features.

Currently, we are rewriting stuff “under the hood” of solph to prepare for future additions, including time-series aggregation. Also, experimental features are removed if they do not mature. (This includes the approach for cellular energy systems, we recommend to use named tuples as labels instead.) Every now and then we try to change our code to eliminate deprecation warnings in time. The release of NumPy 2.0 shows that maintaining compatibility is not always easy. Although it is actually an evolutionary milestone, Pyomo first seemed to be hit between the eyes. ~~In particular, it does not check compatibility of installed dependencies.~~ Never version state to be compatible to numpy<2.0 only, but at least sometimes incompatible versions are installed by pip.

Thus, software relying on Pyomo – such as solph – currently looks broken when latest versions of NumPy are installed. The only option is to downgrade NumPy and wait for Pyomo to update. Not only because this is not the first time Pyomo effectively breaks solph without a warning, we are considering other back-ends. Alternatives also promise faster processing. But this is a big maintenance job, and hard to fund using the current funding scheme of research projects.

solph v0.5.2: Next Network

Today, we had two new releases, oemof.network 0.5.0 (GitHub, PyPI) and oemof.solph 0.5.2 (GitHub, PyPI). The release of the first includes a lot of refactoring and cleaning. The code should now be a lot easier to understand and to maintain. We now use explicit keyword arguments also for network, so typos will be easy to find. Secondly, there is a (still experimental) API to get Nodes by label. At last, we now officially support an API to add Flows between existing Nodes. Using this API in solph, the Nodes might e.g. be Buses:

solph v0.5.1: Compliant Converter

Today, oemof.solph v0.5.1, code name “compilant converter” has been released. (Package at PyPI, Tag at GitHub). The most noteworthy addition is a new (still experimental) feature multi-period (dynamic) investment models. The code name refers to a small but maybe more evident change: The component Transformer is renamed to Converter. This is because people typically think of electrical devices when they hear the word “transformer”. However, as experienced users of our package know, the Transformer is neither meant to be (only) electrical nor bidirectional (as electrical transformers typically are). Thus, the more generic term “converter” is now used. (Note that we always had the argument “conversion_factor”.) To maintain compatibility for v0.5.0, there is a transitional wrapper that still allows to name the component “Transformer”. It will keep telling you about the upcoming change, though. Another usability feature is the presentation of the examples as part of the documentation. Also, we fixed error when calling oemof_installation_test as a console script. It turned out to confuse quite a few new users that it did not work as documented in the previous release.

We hope to have a fair balance between improvements in usability and new (experimental) features to make this an exciting release for all kinds of users. For us, it definitely is.

RC1 of solph 0.5.1

We have a release candidate for v0.5.1 (Package at PyPI, Tag at GitHub). There are some additions, but we also prepare for significant API changes that will come obligatory with v0.6. When upgrading from v0.5.0 to v0.5.1, there should be no changes required for you code. (This is not true if you use features that are explicitly marked “experimental”. Those may change without notice.)

Noticeable changes include:

The component Transformer is now named Converter.
You can now combine Investment and OffsetConverter.
Having energy stored in a GenericStorage can now have a cost.
You can now give an Investment object as the nominal_value. We considered this more intuitive than working with two mutually exclusive different keyword arguments.
Tons of improvements in the (still experimental) MultiPeriod optimisation.

Again, there are transitional wrappers, so nothing should break when updating from v0.5.0, using the new API should be voluntary (you get a warning) for now. It would be nice if you test if your solph v0.5 code still works with this RC. We are aiming for a final release of v0.5.1 by the end of August.

oemof.solph v0.5 released

We are happy to announce oemof.solph v0.5.0 (codename “Rigorous refactoring”) . This release brings an extreme shift towards more user focused design:

Clean definition of time indexes: You need N+1 points in time do define N time spans.
Parts of the energy system graph are now clearly structured into buses, components, and flows. This adds some extra words to imports but makes the underlying logic more transparent.
Public and private API are be more distinguished now. (‘_’ signifies private, public API is defined in init files.)
Experimental code is now sitting in sub-modules called experimental (replaces “custom”).
The flow arguments summed_minand summed_max now have the more descriptive names full_load_time_min and full_load_time_max.
Keyword arguments are now explicit. This will make it easier to find the correct arguments and will also catch typos. Custom attributes can be added using the argument custom_attributes. Those will be passed down the class hierarchy and can (possibly) be handled in parent classes.
Add inactivity_costs as an option for Flows. Inactivity costs is a cost for times where a Flow is not operated.
Examples are added to the documentation. (The format of the examples could be improved, though.)

Besides these changes, there is one big thing that has happened “under the hood”. It is now possible to combine NonConvex and Investment optimisation in the same Flow.

Tag: solph