v0.8

Changelog of the v0.8 release series.

v0.8.3 - Newton’s Nature (June, 21, 2025)

Bug Fixes

  • The export method to_exerpy now includes the results for components (PR #688).

Contributors

v0.8.2 - Newton’s Nature (June, 12, 2025)

API changes

  • The API of the Subsystem class has been revised to make it act more like a Network. You can get components and connections from the subsystem with respective methods, and the SubsystemInterface class is utilized to target the subsystem.inlet and subsystem.outlet in a Connection object. For the required changes please check the respective section in the docs (PR #652).

  • The attribute progress of the class Network has been removed. (PR #684).

  • To raise an AssertionError on non-convergence of a simulation you must now use Network.assert_convergence() instead of Network._convergence_check() (PR #684).

New Features

  • The combustion based component classes CombustionChamber, DiabaticCombustionChamber and CombustionEngine can now handle carbonmonoxide as fuel (PR #674).

  • The Network’s solve method will now assign status values depending of the outcome of the simulation. Check the section on convergence for more information (PR #684).

Other Changes

  • The partial derivatives for specified temperature are only calculated towards enthalpy and pressure, not towards the fluid compostion. The reason for this is, that it is not intended, that the composition of a fluid can be determined by specifying temperature. Removing this saves a lot of computational overhead for mixtures (PR #674).

  • The calculation of the logarithmic temperature difference in heat exchanger classes was error-prone due to rounding differences in temperature. The calculation is now consistent through all respective classes and can handle temperature differences to a precision of 1e-6 (PR #679).

  • The export method to_exerpy now includes the results for components (PR #680).

Contributors

v0.8.1 - Newton’s Nature (May, 29, 2025)

New Features

  • The CoolPropWrapper API can now handle CoolProp based mixtures and allows the user to specify which type of mixture fractions to use (mass, molar, volume). This is mostly for REFPROP support and will require further adaptions for the CoolPropWrapper in the future, because the pure fluid functions may not be applicable in the context of mixtures (PR #655).

    In case you are working with incompressible mixtures, this feature is API breaking. You need to append |mass, |volume or |molar to your fluid name string at the very end to specify, which type of mixture is used. This information can be retrieved from the CoolProp online documentation on the incompressible fluids.

Bug Fixes

  • In case parts of a Network were missing a CycleCloser or a Source and Sink combination a misleading error was raised. These cases are checked for explicitly now to make debugging easier (PR #653).

  • The logging of warnings for HeatExchanger based components includes the label of the component, when cold or hot side effectiveness cannot be calculated (PR #670).

Contributors

Fixes for v0.8.0

Bug Fixes

  • A bug was fixed in CoolProp version 6.8.0 #2447 for the S800 fluid. The tests/examples affected by this in tespy have been updated (PR #640).

  • In case a heat exchanger heats up the same mass flow (e.g. in a recuperator or internal heat exchanger), the derivative to the mass flow was assigned wrong (PR #646).

Other Changes

  • To improve convergence for offdesign calculation and problems with small initial increment of the variables the heuristics for the convergence check based on the components have been adjusted (PR #641).

  • Update code, which was subject to be changed with the major release of 0.8.

Contributors

v0.8.0 - Newton’s Nature (April, 23, 2025)

API breaking changes

  • The OptimizationProblem implements the following changes (see PR #610):

    • The dtype for objective has been changed to list. With a single element list, a single objective optimization is carried out. With lists containing more elements, multi-objective optimization will be carried out.

    • The function argument gen of the run method has been renamed to evo. The same applies for the individuals dataframe.

    • Your tespy model now needs to have a function get_objectives instead of get_objective and it must return a list of values.

    • The intermediate printing during optimization has been removed.

  • Exporting or saving a network state to the filesystem will create a single json file in the future, meaning you need to change the path to "export.json", for example. Also, you need to replace the design_path and init_path arguments for your networks to point to the respective json file. To transform an existing export or save state from the old API of v0.7, you can use the v07_to_v08_export and the v07_to_v08_save methods. They will return a dictionary with the respective data, which you can dump into a .json file.

    This also breaks the API of the tespy.networks.network_reader.load_network method, meaning exported network data based on tespy<0.8 are not compatible with how tespy>=0.8 is handling the data. Use the described method above to adjust that. On top of that, instead of the load_network method, use the from_json class method to import networks in the future:

    Saving a state of the network and using it to initialize

    >>> from tespy.networks import Network
>>> from tespy.connections import Connection
>>> from tespy.components import Source, Sink
>>> nwk = Network(iterinfo=False)
>>> so = Source("source")
>>> si = Sink("sink")
>>> c1 = Connection(so, "out1", si, "in1", label="1")
>>> nwk.add_conns(c1)
>>> c1.set_attr(m=1, p=10, T=100, fluid={"air": 1})
>>> nwk.solve("design")
>>> data = nwk.save("design.json")
>>> nwk.solve("design", init_path="design.json")

    Saving the state of the network to csv files

    You can also export your state to a folder + csv files tree.

    nwk.save_csv(“csv_state_export_folder”)

    Exporting and Importing a Network

    The export of the network is written to the specified path, and will return the data as a dictionary as well. If you only want to retain the data without writing them to the filesystem, you can call the method without passing a path.

    >>> data = nwk.export("tmp.json")
>>> list(data.keys())
['Network', 'Connection', 'Component']
>>> list(data["Component"])
['Sink', 'Source']
>>> imported_nw = Network.from_json("tmp.json")
>>> data_without_json_writing = nwk.export()
>>> list(data_without_json_writing["Connection"]["Connection"])
['1']

    Diff: (PR #605 and PR #638 <https://github.com/oemof/tespy/pull/638>).

New Features

  • The parameter for delta pressure (dp) is now available on all components, that do feature the pressure ratio pr parameter (PR #628).

    Attention

    Please note, that the dp parameter follows the network unit specification for pressure. If your network unit is bar, then the pressure drop will also use bar as unit.

  • Modify the OptimizationProblem class to allow multi-objective optimization (PR #610).

  • Component bypassing is now possible by specifying bypass on a component. This applies pressure and enthalpy equality to the inlet and corresponding outlet connection pairs of components. This only works for single inlet-single outlet components as well as heat exchanger components with two sides (PR #615).

    >>> from tespy.networks import Network
>>> from tespy.connections import Connection
>>> from tespy.components import Source, Sink, SimpleHeatExchanger

>>> nw = Network()
>>> nw.units.set_defaults(
...     pressure="bar",
...     temperature="°C",
...     enthalpy="kJ / kg"
... )
>>> nw.iterinfo = False

>>> source = Source("In")
>>> sink = Sink("Out")
>>> heater = SimpleHeatExchanger("Heater")

>>> c1 = Connection(source, "out1", heater, "in1", "1")
>>> c2 = Connection(heater, "out1", sink, "in1", "2")

>>> nw.add_conns(c1, c2)

>>> c1.set_attr(T=100, p=2, m=1, fluid={"water":1})
>>> heater.set_attr(Q=2e6, pr=0.9)

>>> nw.solve("design")

>>> heater.set_attr(bypass=True)
>>> nw.solve("design")

Contributors