New solph release: v0.5.4

We released two new versions of solph. One is a stable maintenance release (solph 0.5.4 at PyPIsolph 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.

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:

Continue reading “solph v0.5.2: Next Network”

solph v0.5.1: Compliant Converter

Today, oemof.solph v0.5.1, code name “compilant converter” has been released. (Package at PyPITag 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.

oemof.tabular 0.0.3: New release on PyPI

We are happy to announce that we have released a new version of oemof.tabular. Oemof.tabular allows to create energy systems from tabular datapackages, which makes it easy to build models without writing a lot of code.

The focus of the release has been the adaption of tabular to oemof.solph 0.4.5. The following changes have been made:

  • Adjusted to new oemof.solph structure.
  • Allowed definition of costum foreign keys. Keys and related descriptors are now read from config files (.json) and can be adopted by setting environment variables using custom config files.
  • Added constraint tests for most facades.
  • Reduced number of imported packages.
  • Cleaned up the badges in README.
  • Moved CI services to GitHub actions.

The following issues have been fixed:

  • Fixed Link by not setting constraints that limit direction.
  • Fixed storage investment with existing capacities
  • Introduced a conditional to fix error when running datapackages with expandable links.
  • Fixed typo in the attribute variable_costs in facades.py.
  • Introduced marginal costs for both output flows instead of only one to avoid elimination of energy.

A detailed summary can be found here.