v0.3.0 - Mayer’s Merit (May, 21, 2020)#

TESPy version 0.3.0 - Mayer’s Merit comes with a lot of new features and a publication in the Journal of Open Source Software. The paper is available at the website of the JOSS.

BibTeX citation:

@article{Witte2020,
    doi = {10.21105/joss.02178}
    year = {2020},
    publisher = {The Open Journal},
    volume = {5},
    number = {49},
    pages = {2178},
    author = {Francesco Witte and Ilja Tuschy},
    title = {{TESPy}: {T}hermal {E}ngineering {S}ystems in {P}ython},
    journal = {Journal of Open Source Software}
}

New Features#

  • Make entropy myconn.s.val or myconn.s.val_SI and specific volume myconn.vol.val or myconn.vol.val_SI respectively available after simulation (PR #172).

  • Connections, components and busses are now easily accessible on every network. Connections now have a label, which can be specified individually, the default value of the label is given by the following logic. source:source_id_target:target_id, where source and target are the labels of the connected components.

    Access the objects with:

    • mynetwork.busses[‘mybuslabel’]

    • mynetwork.components[‘mycomponentlabel’]

    • mynetwork.connections[‘myconnectionlabel’]

    (PR #173)

  • Specification of the CoolProp back end is now possible. You can specify the back end by adding it in front of the fluid’s name on creating a network, for example:

    from tespy.networks import network
    fluid_list = ['air', 'BICUBIC::water', 'INCOMP::DowQ']
    network(fluids=fluid_list)
    

    If you do not specify a back end HEOS will be applied (as for air in this example). This has been the case until now as well, thus no further changes are required to match an 0.2.x application to the 0.3.x API. For all back ends available please refer to the fluid properties section. To specify the fluid vector on a connection leave out the back end specification, e.g.:

    myconnection.set_attr(fluid={'DowQ': 1, 'water': 0, 'air': 0})
    

    (PR #174).

  • Unsetting a value is now also possible using None instead of np.nan (PR #178).

  • It is possible to choose a base for your components when adding them to a bus:

    • 'component': This means, the efficiency definition of the bus is

      \[\eta=\frac{\dot{E}_\mathrm{bus}}{\dot{E}_\mathrm{component}}\]
    • 'bus': This means, the efficiency definition of the bus is

      \[\eta=\frac{\dot{E}_\mathrm{component}}{\dot{E}_\mathrm{bus}}\]

    These definitions also apply to the characteristic line usage. The default setting (if you do not specify the base) uses 'base': 'component'. You therefore do not need do adapt your scripts regarding this change. For an example of the bus usage see the examples section below (PR #157).

  • Within the busses’ printouts the efficiency of every component on the respective bus is displayed. Additionally, it is possible to get the bus value and the efficiency of a specific component on a specific bus.

    • to get the bus value use mycomp.calc_bus_value(mybus) and

    • to get the efficiency use mycomp.calc_bus_efficiency(mybus)

    where mycomp is a component object and mybus is a bus the component has been added to (PR #157).

  • New component tespy.components.nodes.droplet_separator for separation of a single fluid in two phase state into saturated gas and saturated liquid phase. An example is given in the docstrings of the class documentation (PR #186).

  • New component tespy.components.heat_exchangers.parabolic_trough for concentrated solar power simulation. An example is given in the docstrings of the class documentation (PR #191).

  • New property min_iter of the tespy.networks.networks.network class, allowing to specify the minimum amount of iterations before a solution is accepted (PR #197).

Documentation#

  • Documentation has been updated according to the API-changes.

  • Fixed many typos on the online-documentation.

Parameter renaming#

  • Adding components to a bus now requires 'comp' instead of 'c' and 'param' instead of 'p' (PR #157).

  • The former parameter kA has been renamed to kA_char as the behavior in offdesign was following a characteristic instead of a constant value. Additionally a new parameter kA has been implemented, which represents a specified constant value for kA in both design and offdesign cases (PR #199).

Testing#

  • Move from nose to pytest (PR #165).

  • Add fluid property test for a mixture of a tespy_fluid with a third fluid and a mixture of the same individual fluids (PR #174).

  • Add a gasturbine model test for comparison of the stoichiometric combustion chamber with the standard combustion chamber (PR #174).

  • Add bus tests for efficiency definitions (PR #157).

  • Add Python 3.8, PEP and documentation build tests (PR #201).

Bug fixes#

  • Increase the number of support points for tespy_fluid tabular data creation in order to lift accuracy to a more acceptable value (PR #174).

  • Fix the default characteristic line for compressor isentropic efficiency: The line did not have an intersection with the point 1/1 (PR #196).

  • If a temperature value of a mixture was not found within the maximum number of newton iterations in the tespy.tools.fluid_properties module, the wrong value was still displayed in the output without a warning. In this case, the value will be nan in the future and a warning message is displayed (PR #200).

Other changes#

  • Improve naming in networks, components and connections modules (PR #172, PR #175).

  • The Parameter T_range of networks is deprecated. The fluid property calls for mixtures have been modified to prevent errors when the temperature of the mixture is below the minimum or above the maximum temperature limit of a component of the mixture (PR #200).

  • Restructure package skeleton (PR #201).

Changes in the API#

The changes affect

Data generated in older versions of TESPy can not be imported. In order to fix this follow the steps below.

  • rename the comps folder to components

  • rename the conns.csv file to connections.csv

and within the file rename the columns

  • s to source

  • s_id to source_id

  • t to target

  • t_id to target_id

If you want to use the network reader,

  • create a network.json file.

  • add the desired contents as listed below.

The fluids are represented in a dictionary containing the fluid’s names as keys and the CoolProp back end as value. "HEOS" is the default back end, which has been used until version 0.2.x in TESPy.

{
    "fluids":
    {
        "CO2": "TTSE",
        "O2": "HEOS",
        "N2": "BICUBIC",
    },
    "T_unit": "C",
    "h_unit": "kJ / kg",
    "m_unit": "kg / s",
    "h_range": [150, 3000]
}

If you are having trouble applying these changes, you are welcome to open an issue on our github repository.

Example#

We have added a code example below to underline the changes regarding the bus usage. Simply, a pump is connected to a source and a sink. The pump’s efficiency and pressure rise are defined. We define three different busses and add the pump to these busses with a given efficiency value of 0.95.

from tespy.components import pump, sink, source
from tespy.connections import bus, connection
from tespy.networks import network

nw = network(fluids=['H2O'], p_unit='bar', T_unit='C')

si = sink('sink')
so = source('source')
pu = pump('pump')

so_pu = connection(so, 'out1', pu, 'in1')
pu_si = connection(pu, 'out1', si, 'in1')

nw.add_conns(so_pu, pu_si)

bus1 = bus('bus 1')
bus1.add_comps({'comp': pu, 'char': 0.95, 'base': 'bus'})

# this yields a bus value smaller than the component value!!
bus2 = bus('bus 2')
bus2.add_comps({'comp': pu, 'char': 0.95, 'base': 'component'})

bus3 = bus('bus 3')
bus3.add_comps({'comp': pu, 'char': 1 / 0.95, 'base': 'component'})

nw.add_busses(bus1, bus2, bus3)

so_pu.set_attr(fluid={'H2O': 1}, m=10, p=5, T=20)
pu_si.set_attr(p=10)

pu.set_attr(eta_s=0.75)

nw.solve('design')
nw.print_results()

As you can see, the components value of the bus will always be the same. Due to the efficiency definitions as mentioned in the new features, the bus value of bus3 and bus1 are identical. bus3 implements the method applied so far (in case of a motor at least) and bus1 implements the new efficiency definition based on the bus value. For bus2 the efficiency definition is based on the component, thus the bus value is lower than the component value (which would be great in case of a motor, but unfortunately some thermodynamic experts may have issues with that…).

Contributors#