text:
# What’s New#

Discover noteable new features and improvements in each release

## v0.6.3 - Development in Progress#

### New Features#

• A new TESPy logger has been implemented to capture TESPy specific loggings with a constant string id for the logger object that is retrieved from the logging module. This allows to modify the logging functionality in a programmatic way and simplifies the work that has to be done in libraries and applications that consume the TESPy library (PR #390).

• A progress bar for the iterations has been integrated (PR #391).

### Other Changes#

• Rename comp_init method of components to preprocess (PR #404).

## v0.6.2 - Leidenfrost’s Library Hotfix (October, 14, 2022)#

### Bug Fixes#

• The Network’s component DataFrame is updated when connections are removed from the Network (PR #365).

## v0.6.1 - Leidenfrost’s Library (October, 02, 2022)#

We have completely revised the documentation improving the overall structure and introducing a modern look (PR #355). Have fun exploring the website!

### Documentation#

• Fix some typos in the online documentation (PR #342).

• New tutorial on starting values for a subcritical heat pump setup (PR #346).

## v0.6.0 - Colored Chemicals (May, 15, 2022)#

We have created a place for users of TESPy to exchange ideas and share their models and experience. Everyone is invited to get in touch and tune in on our GitHub discussions page.

### Documentation#

• Add tutorial for the DiabaticCombustionChamber (PR #321).

• Fix a lot of bugs in the docs (PR #337).

### Bug Fixes#

• Calculation of entropy for gaseous mixtures included the pressure correction term although the entropy values of the mixture components were calculated at their respective partial pressure (PR #318).

• Fix mass flow multipliers for non SI units (PR #317).

• Fix call to wrong (hard coded) key for molecular mass of hydrogen (PR #332).

• Fix some typos in the documentation of the class tespy.components.reactors.water_electrolyzer.WaterElectrolyzer (PR #335).

• Fix an error in the aggregated results of components and busses in the exergy analysis in case the temperature at turbomachinery is less than or equal to ambient temperature (PR #340).

### Other Changes#

• The component CombustionChamberStoich has been removed (PR #321).

• The fluid property back-end TESPyFluid has been removed (PR #321).

## v0.5.1 - Exciting Exergy (January, 14, 2022)#

### Documentation#

• Improvements on the description of the exergy analysis results data. Additional dataframe added, that contains the aggregated component exergy analysis results (component and respective bus exergy data) (PR #293).

### Bug Fixes#

• In the first offdesign calculation the connection parameter specifications in the LaTeX report were still reported in design mode (PR #290).

• Labels of string representations of numeric labels in components, connections and busses have been misinterpreted as numeric values by the network_reader (PR #298).

## v0.5.0 - Davis’ Domain (September, 29, 2021)#

### Documentation#

• Add a tutorial for the exergy analysis of a ground-coupled heat pump (GHCP). You can find it on the Tutorials and Examples pages (PR #282).

### Bug Fixes#

• Add is_result flag to logarithmic temperature difference of heat exchangers.

• Lift pandas requirement to pandas>=1.3.0 (PR #285).

### Other Changes#

• LaTeX model report can now be compiled by default (PR #286).

## v0.4.4 - Reynolds’ Reminiscence (July, 14, 2021)#

### Documentation#

• Fix some typos here and there.

### Other Changes#

• Add warning logs for missing fluid composition data in the initialisation process of the network (PR #278).

• Add Dodecane to the available fuels for combustion (PR #273).

• Add tests for the solar energy generating system (PR #280).

## v0.4.3-003 - Grassmann’s Graph (May, 17, 2021)#

### Documentation#

• Fix typos in the HeatExchanger classes API docs.

• Add two more examples for exergy analysis setups.

### Other Changes#

• Remove Python3.6 support.

• Make it possible to include results in automatic model report, for more information see the corresponding section in the documentation: TESPy Networks Postprocessing (PR #267).

## v0.4.3-001 - Grassmann’s Graph (May, 12, 2021)#

### Documentation#

• Some minor changes in documentation.

### Other Changes#

• Check for key in dictionary instead of key in dictionary.keys() in boolean operations (PR #264).

• Rename GitHub branches: master to main (Issue #266).

## v0.4.3 - Grassmann’s Graph (April, 29, 2021)#

### New Features#

• Automatic provision of input data for the sankey diagram class of the plotly library to generate exergy sankey diagrams. For example, the diagram of the solar thermal power plant presented in the thermodynamic analyses section

(PR #251).

• The results of your simulation are much more easy to bulk access: The tespy.networks.network.Network class provides you with a results dictionary containing DataFrames with all data necessary. The keys of the dictionary are:

• 'Connection'

• the class names of the different components used, e.g. 'Turbine' or 'HeatExchanger'

• the labels of the busses, e.g. 'input power'

The pandas DataFrame provides you with the SI-values for components and busses as well as all fluid property data of the connections in respective specified unit. For example:

mynetwork.results['Connection']
mynetwork.results['Turbine']

(PR #255).

### Bug Fixes#

• Add missing exergy balance method of class Drum (#1eb92e3).

• Add missing specified values of temperature difference to boiling point to connection report (PR #250).

• Fix Reynolds value ranges for Hanakov and Blasius equations in calculation of Darcy friction factor (#ce6bef9).

## v0.4.2 - Fixes for User’s Universe (February, 11, 2021)#

### API Fixes/Changes#

• Due to a bug/double structure in the network properties of a model, specification of component or connection parameters when the component or connection instance was accessed via its label within the network, the wrong copy of the instance was accessed when using PyGMO in some cases. The method off accessing components and connections via label has therefore changed in the following way.

Old method:

conn = mynetwork.connections['connection label']
comp = mynetwork.components['component label']

New method:

conn = mynetwork.get_conn('connection label')
comp = mynetwork.get_comp('component label')

To iterate through all components or connections of the network use something like:

for conn in mynetwork.conns['object']:
print(conn.label)

for comp in mynetwork.comps['object']:
print(comp.label)

Accessing busses remains untouched (PR #247)

### Bug Fixes#

• Saving data of characteristics and reloading from the .csv file structure was broken if more than one component of the same class was part of the network (PR #246).

## v0.4.1 - User’s Universe (February, 7, 2021)#

### New Features#

• Add functionalities for user defined equations. The user can define individual functions that can be applied on connection parameters. E.g. in order to couple mass flow values at some point of the network to temperature values at a different point. Generic equations can be applied: There are no restrictions as long as the partial derivatives are provided correctly. For extensive examples have a look at the API documentation of class tespy.tools.helpers.UserDefinedEquation or in the respective section in the online documentation (PR #245).

### Bug Fixes#

• Fix RuntimeError in CombustionChamberStoich class (PR #244).

## v0.3.4 - Darwin’s Delight (October, 13, 2020)#

### Documentation#

• Replace enthalpy starting value with state keyword in the heat pump tutorial and the examples from the oemof_examples repository (PR #214, 743bfeb).

• Add a new tutorial for efficiency optimization of a thermal power plant using TESPy and PyGMO (PR #220).

• Fix some typos in the BibTeX data for the TESPy JOSS paper (PR #220).

### Bug Fixes#

• Update the dictionary of busses, components and connections before every calculation. If a parameter is updated by user specification using the dictionary access method and the network object is copied, the dictionaries of the busses, components and connections point to a different object in some cases (d2537ca).

## v0.3.3 - Maxwell’s Memory (July, 21, 2020)#

### New Features#

• In some cases - especially large networks and many simulation runs within a a single script - the fluid property memorisation added a lot of calculation time for searching through the lookup tables of previously calculated fluid property values. It is now possible to manually specify whether or not the fluid property memorisation is performed.

The memorisation benefits

• networks using gaseous mixtures and

• smaller networks using the HEOS back end.

The memorisation slows down

• very large networks and

• usage of tabular back ends (BICUBIC or TTSE).

In order to deactivate memorisation, add memorise_fluid_properties=False on network creation, for example:

from tespy.networks import network

mynetwork = network(
fluids=['BICUBIC::water'], memorise_fluid_properties=False)

(PR #211).

### Other Changes#

• Reorder network initialisation process for improved maintenance and faster performance (PR #204).

## v0.3.2 - Carnot’s Colors (June, 10, 2020)#

### New features#

• Colored printouts are available in the print_results() method of the network class. There are three different color codes available with default settings:

• user specified parameters ('set', blue)

• component parameters specified as variables ('var', green)

• faulty parameters ('err', red)

In order to change the colors, simply import coloring from the tespy.tools.global_vars module and adjust the escape codes. For example, to reset all colors to white text:

from tespy.tools.global_vars import coloring
coloring['set'] = '\033[0m'
coloring['err'] = '\033[0m'
coloring['var'] = '\033[0m'

See here for a list of available codes (PR #205).

### Bug fixes#

• Readd method for T_mix_ps calculation for pure fluids: In case the fluid propagation did not go through (e.g. due to availability of good starting values) the fluid composition at a turbomachine’s inlet and outlet may not be equal (PR #207).

• Fix the calculation of mixture density: The density is calculated as sum of the densities of the mixture components at their respective partial pressure and the mixture temperature (PR #207). With the old method, the specific volume was calculated according to Amagat’s law, which produced incorrect values if one or more components of the mixture were liquid at the mixture’s temperature and pressure. See discussion about humid air propreties here: Issue #206.

## 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')

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'})

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…).

## v0.2.2 - Rankine’s Realm (March, 6, 2020)#

### New Features#

• Allow initialisation for the primary variables from previous calculation. Until now, the user needed to save the network’s state and reload that state for his next simulation. This feature is enabled as default. If you want to disable this feature, you need to state mynetwork.solve(..., init_previous=False) (PR #156).

• Extrapolation for characteristic lines is available. In default state, the upper or lower value range limit is used when a characteristic line is evaluated outside of the available x-value range. The extrapolate parameter allows linear extrapolation, for an example see the corresponding sections in the online documentation: component characteristics, tespy characteristics (PR #159).

• Add a new component evaporator for geothermal organic rankine cycle. The component has inlets for geothermal steam brine. On the cold side, the orc working fluid is evaporated. Read more about this component in the API documentation: tespy.components.customs.orc_evaporator (PR #148).

### Documentation#

• Add method for automatic citations and references (PR #163).

### Testing#

• Add convergence checks for all component tests. Some tests did not fail, even if the calculation did not converge (PR #153).

• Improve coverage of the networks module (PR #153).

• Add tests for characteristic line and map evaluation (PR #159).

### Bug fixes#

• Fix the bugged tests for compressor characteristic maps (tespy.components.turbomachinery.compressor.char_map_func()). The pressure ratio factor of the lowest speedline available in the default data ranges from about 0.2 to 0.5. Therefore the design pressure ratio should be higher than 5 (PR #156).

### Other changes#

• Use the method tespy.components.components.component.fluid_deriv() for all components, that do not change composition between an inlet and the respective outlet (PR #153).

• Adjust the method tespy.components.components.component.zeta_func() to work with all zeta value specifications (PR #153).

## v0.2.1 - Fourier’s Fable (February, 7 2020)#

### New Features#

• Back end modifications in order to improve calculation speed. For the results see (PR #147).

### Documentation#

• Fixes in code and docstrings to meet PEP8 guidelines (PR #143).

• Update the class documentations of component and connection classes (PR #146).

### Testing#

• Improve the heat pump test (PR #150).

### Bug fixes#

• Prevent pandas 1.0.0 installation due to bug in the to_csv() method (bug will be fixed in PR #31513 of pandas). Additionally,the version requirements of third party packages have been updated to prevent future bugs resulting from possible API changes (PR #146).

• There was a bug in the heat exchanger kA-functions ( tespy.components.heat_exchangers.simple.kA_func(), tespy.components.heat_exchangers.base.kA_func() and tespy.components.heat_exchangers.condenser.kA_func()). The factors for the heat transfer coefficient should not simultaneously amplify the value but instead with their inverse.

$f_{kA} = \frac{2}{\frac{1}{f_{kA,1}} + \frac{1}{f_{kA,2}}}$

For simple heat exchangers, $$f_{kA,2}$$ will be equal to 1 (PR #150).

### Other changes#

• Replacing some of the characteristic lines by generic ones. The simulation results using the default lines might slightly differ from the results using the original defaults (PR #149).

### Contributors#

• Francesco Witte (@fwitte)

• @maltefritz

## v0.2.0 - Clausius’ Circus (January, 15, 2020)#

TESPy Clausius’ Circus includes many back end adjustments for future development. Additionally, some new features have been implemented improving the usage of the software. Due to changes in the API, version 0.2.0 will not be compatible with older versions of TESPy!

### New Features#

• Implemented a new component “cycle_closer”. This component may serve as substitute for a sink/source or splitter/merge combination in closed cycle simulations (PR #107).

• Added optical efficiency to the “solar_collector”. The incoming radiation E no longer represents the actual absorption but the radiation on the collector surface area (PR #110).

• Parameters local_design and local_offdesign are now also available for network exports and imports (PR #109).

• Busses, components and connections are now equipped with printout attribute. For example, if you specify myconn.set_attr(printout=False) the results of the specified connection will not be printed by the print_results method of your network. This is especially useful, if you have a large network and only want to print the results at the most important points (PR #126).

• It is possible to place custom characteristic lines and maps in the HOME/.tespy/data folder and import these for your TESPy scripts. Have a look at the documentation for more information (PR #118).

• If the network check fails due to component inlets or outlets being connected to more than one connection at a time, all connections are printed for easier network topology debugging (PR #135).

### Documentation#

• Full review of online documentation (PR #112).

• Full review of the examples repository (PR #46 of oemof_examples).

• Plots of default characteristic lines and maps are generated automatically on documentation build (PR #139).

### Parameter renaming#

• New name for cogeneration_unit: combustion_engine (PR #105).

• New name for subsys_interface: subsystem_interface (PR #107).

• The module import shortcuts (from tespy import ...) for components (cmp), connections (con), helpers (hlp), logger (logger), networks (nwk), network_reader (nwkr) are no longer supported (PR #108)! We instead implemented new shortcuts instead for tespy.networks and tespy.components modules (PR #118).

• The method set_printoptions for the tespy.networks.networks.network class is not available anymore. Use yournetwork.set_attr(iterinfo=True/False) in future (PR #109).

• Parameter interface for sinks and sources has been removed (PR #109).

• The method for loading networks from the network_reader module has been renamed from load_nwk to load_network (PR #118).

### Testing#

• Improved doc-test for class tespy_fluid (PR #109).

• Add doc-test for fluid_structure function of tespy.tools.helpers (PR #109).

• Reworked a lot of examples in the components API-documentation (PR #109).

• Update software tests (PR #111).

• Add value limit test for newton-algorithm (PR #129).

### Bug fixes#

• Bus value specification uses is_set instead of val_set as the component properties data container is used (39ca830).

• Parameters local_design and local_offdesign are now also available for network exports and imports (PR #109).

• Busses and characteristics are not exported, if none are used in the network. The network_reader can now handle missing bus.csv, char_line.csv and char_map.csv (PR #127).

• Some parameters of class combustion_engine have been printed out twice in the value range check (PR #135).

### Other changes#

• Adjust logging levels for grouped component parameter initialisation (PR #111).

• Implement pep8speaks (PEP8 checker) in GitHub repository (PR #131).

• The subsystem architecture has been simplified. Your connections and components are saved to dictionaries to make accessing the individual properties much easier (PR #126). For a use case of subsystems, have a look at the district heating example.

• Change the specification of set value for dc_simple class from val_set to is_set (PR #138).

• Move the default characteristic function plots to the tespy.data module documentation (PR #138).

### Contributors#

• Francesco Witte (@fwitte)

• @MarBrandt

• @maltefritz

• @jfreissmann

• @stianchris

• @FranziPl

### Examples#

Removed default import shortcuts

tespy 0.1.x

from tespy import cmp, cmp_char, con, hlp, logger, nwk, nwkr, subsys

tespy 0.2.x (example imports)

from tespy.components import heat_exchanger, turbine
from tespy.connections import connection, bus, ref
from tespy.tools import char_line, char_map
from tespy.tools import logger

Renaming components

tespy 0.1.x

from tespy import cmp
chp = cmp.cogeneration_unit('combined heat and power')
IF = cmp.subsys_interface('subsystem interface')

tespy 0.2.x

from tespy.components import combustion_engine, subsystem_interface
chp = combustion_engine('combined heat and power')
IF = subsystem_interface('subsystem interface')

Renaming tespy.networks functionalities

tespy 0.1.x

from tespy import nwkr
mynetwork.set_printoptions(print_level='none')
mynetwork.set_printoptions(print_level='info')

tespy 0.2.x

from tespy.networks import load_network
mynetwork.set_attr(iterinfo=False)
mynetwork.set_attr(iterinfo=True)

Component characteristic specification

tespy 0.1.x

from tespy import cmp, hlp
turb = cmp.turbine('turbine')
x = [0.50, 0.75, 1.00, 1.25]
y = [0.90, 0.98, 1.00, 0.99]
char = hlp.dc_cc(is_set=True, x=x, y=y)
turb.set_attr(eta_s_char=char)

tespy 0.2.x

from tespy.components import turbine
from tespy.tools import char_line
turb = turbine('turbine')
x = [0.50, 0.75, 1.00, 1.25]
y = [0.90, 0.98, 1.00, 0.99]
char = dc_cc(is_set=True, func=char_line(x, y))
turb.set_attr(eta_s_char=char)

## v0.1.4 (December, 12, 2019)#

### New Features#

• Implemented difference pressure vs mass flow characteristic line for valve (c4eec6d).

### Documentation#

• Fix typos in docstrings in components module (PR #102).

### Other changes#

• This is the last release before version 0.2.0.

### Contributors#

• Francesco Witte

## v0.1.3 (November, 6, 2019)#

### New Features#

• Individual design path specification is available: Specify the design_path individually for single connections or a components in your network, if you want the individual design parameters be loaded from a different design case than the network’s design case given in the network’s design path (PR #84).

• Implement local design and local offdesign features: It is possible to design a plant while some parts of the plant are in offdesign mode. This is useful, e.g. when designing an extraction turbine, where the district heating condenser is designed for maximum extraction and the backpressure turbine is designed for minimum extraction (PR #92).

• Implement warning messages for all components, if the component’s properties are out of physical bounds. The bounds can be customized when specifying a property by data containers (read more at component parameter specification), (PR #85).

### Documentation#

• Change license from GPLv3 to MIT (PR #93).

• Fix unit error in component documentation for the zeta-value (PR #93).

• Improve documentation of the functions tespy.components.components.component.zeta_func() and tespy.components.components.component.zeta2_func() (4291bd).

### Testing#

• Added tests for the new design path feature (PR #84).

• Implemented additional network and component tests, (PR #86).

### Bug fixes#

• Offdesign values for connections are specified from the design case files (PR #84). Before, the offdesign values were the actual values of the fluid property in the last calculation (which is not necessarily the design case).

• Add debug logging message, if the enthalpy is adjusted on connections with the keyword state specified (PR #85).

### Other changes#

• Improved calculation speed for fluid mixture properties with the parameter T0 as starting value for root finding (PR #84).

### Contributors#

• Francesco Witte

## v0.1.2 (August, 6, 2019)#

### New Features#

• The water electrolyzer is available as new component of TESPy (PR #73).

• The components combustion chamber and cogeneration unit now work with fuel mixtures, too. Specification of the component’s fuel is not required anymore, the software automatically detects, which fuels are connected to the component’s inlets. Available fuels are: methane, ethane, propane, butane and hydrogen (PR #79).

• Add busses to the network's result printout.

### Documentation#

• Fix some typos in the docstrings and improvements of default values (PR #69 and PR #71).

• Update combustion chamber tutorial (PR #79).

• Improve API documentation of the solar collector: Handling of optical losses (PR #83).

### Bug fixes#

• Fix convergence check for negative minimum enthalpy values (PR #71).

• Add an error message if the user did not add any connections to the network (PR #79).

• Fix loading bus information from design-case .csv-file. Components can be attached to multiple busses now (PR #79).

• Fix solar collector energy balance equation and adjust documentation (PR #83).

### Other changes#

• Add method to calculate and export vapour mass fraction values of pure fluids in the post processing (PR #74).

• Only allow label and P as parameters for busses to avoid misleading parameter specification (PR #78).

### Water Electrolyzer Example#

from tespy import cmp, con, nwk

fluid_list = ['O2', 'H2O', 'H2']
nw = nwk.network(fluids=fluid_list, T_unit='C', p_unit='bar')

# sinks and sources
fw = cmp.source('feed water')
oxy = cmp.sink('oxygen sink')
hydro = cmp.sink('hydrogen sink')
cw = cmp.source('cooling water')
cw_hot = cmp.sink('cooling water out')

# specification of electrolysis efficiency
el = cmp.water_electrolyzer('electrolyzer 1', eta=0.8, design=['eta'], offdesign=['eta_char'])

# hydrogen compression
comp = cmp.compressor('compressor', eta_s=0.9)

# specify the feed water mass flow
# the fluid composition at the feed water inlet and the oxygen as well as
# hydrogen outlets are not required. These parameters are set automatically.
fw_el = con.connection(fw, 'out1', el, 'in2', m=0.1, p=10, T=15)
el_o = con.connection(el, 'out2', oxy, 'in1')
el_cmp = con.connection(el, 'out3', comp, 'in1', T=50)
cmp_h = con.connection(comp, 'out1', hydro, 'in1', p=50)

# cooling water specifications
cw_el = con.connection(cw, 'out1', el, 'in1', fluid={'H2O': 1, 'H2': 0, 'O2': 0}, p=5, T=15)
el_cw = con.connection(el, 'out1', cw_hot, 'in1', T=45, p=4.9)
nw.add_conns(fw_el, el_o, el_cmp, cmp_h, cw_el, el_cw)

# solve design case
nw.solve('design')
nw.save('tmp')
# test offdesign case
nw.solve('offdesign', design_path='tmp')

# change feed water flow and recalculate operation
fw_el.set_attr(m=0.05)
nw.solve('offdesign', design_path='tmp')

### Contributors#

• Francesco Witte

• Tim Hoener, Nils Stolze, Markus Brandt

## v0.1.1 (May, 14, 2019)#

### New Features#

• Specifcation of temperature below or above boiling point temperature with Td_bp keyword on connections (PR #64).

• Path specifications for the init_path and design_path in the networks module as well as path in the network_reader module now work with relative and absolute paths. The feature has been tested on windows and linux machines (PR #66).

### Documentation#

• Updated “Using TESPy” according to the new features, you can find an Example for the usage of the Td_bp and the state keyword at the bottom of this release message.

### Testing#

• Tests and doctests have been adjusted and updated to test the new features.

• Added software tests for OS X (PR #68), windows tests to follow.

### Bug fixes#

• Fixed naming-error on windows when creating tespy_fluids (PR #60).

### Other changes#

• Modified printouts of connection properties for network.print_results()-function (668ca6)

• Changed access to imported network’s connections (mynetwork.imp_conns['{source}:{source id}_{target}:{target id}'], replace {...} by the respectve component or id). (a5a867).

• Improved convergence stability for temperatures specified near to the two phase area using the keyowrd state='l' (for liquid) or state='g' (for gaseous). The convergence check manipulates the enthalpy values at this connection in order to meet the phase specification (PR #64).

### Example#

from tespy import cmp, con, nwk
import numpy as np

# network
fluid_list = ['NH3', 'water']
nw = nwk.network(fluids=fluid_list, T_unit='C', p_unit='bar', h_unit='kJ / kg')

# components
tesin = cmp.sink('TES in')
tesout = cmp.source('TES out')
hsin = cmp.sink('HS in')
hsout = cmp.source('HS out')
he = cmp.heat_exchanger('heat exchanger')

# connection
tes_he = con.connection(tesout, 'out1', he, 'in2')
he_tes = con.connection(he, 'out2', tesin, 'in1')
hs_he = con.connection(hsout, 'out1', he, 'in1')
he_hs = con.connection(he, 'out1', hsin, 'in1')

# heat exchanger parameters
he.set_attr(pr1=0.98, pr2=0.98, ttd_u=42, Q=-90e3)

# hot side parameters
hs_he.set_attr(T=70, p=9.4, fluid={'NH3': 1, 'water': 0})
he_hs.set_attr(T=35)

# cold side inlet
tes_he.set_attr(T=18, p=5, fluid={'NH3': 0, 'water': 1})

# solve
nw.solve('design')

fill = '############################################################'

print(fill)
print('See, the calculation did not work: The temperature value for the '
'hot side outlet is near to the two phase region. A singularity '
'appears in the solution process, as the temperature equation\'s '
'derivative towards enthalpy will be zero in this region.')
print(fill)

## let's retry with state keyword (state should be gaseous)
he_hs.set_attr(state='g')

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

print(fill)
print('The state keyword prevents the fluids state at the hot side outlet '
'from going into two phase region, a solution is found.')
print(fill)

# so how does the superheating or subcooling work?
# remove state and temperature specification, add superheating specification
# temperature difference to boiling point = 10 K
he_hs.set_attr(state=np.nan, T=np.nan, Td_bp=10)
nw.solve('design')
nw.print_results()

print(fill)
print('The temperature at hot side outlet is 10 K above the (prior) unkown '
'boiling point temperature at that point.')
print(fill)

### Contributors#

• Francesco Witte

• Shuang Chen

## v0.1.0 (February, 2, 2019)#

### New Features#

• Added new component node and modified equations for simple heat exchangers to work with negative mass flows. The node component is able to switch between merge and splitter equations according to the directions of the mass flows. Please beware, that the amount of the equations of a splitter and a merge is not the same, thus the number of equations provided by the node depend on the flow direction and may change within the calculation process. In order to make use of the node, a network should always contain more than one node, so that a different node can compensate a possible change in flow direction (PR #43).

• Added examples for components, busses, connections etc. in the docstrings. You will find the examples in either your editors help pane or the online documentation of the API (PR #45).

• Added an interface attribute for sinks and sources changing the component type from sink/source to subsys_interface when exporting the network, if you specify interface=True for these type of components. This way, you can reimport the saved network and connect it to a different network. Also imported components, connections and busses are easily accessible by their label (components/busses) or their target with target id (connections). For an example, see the module documentation tespy.network_reader. (PR #46).

• Added logging (console and log-file), see how to use it (PR #51).

### Documentation#

• Adapted documentation and examples in regard of new features. Examples have been moved to the oemof-examples repository.

• Improved consistency in documentation of all modules (PR #45).

• Registered a DOI for TESPy version 0.1.0.

### Parameter renaming#

networks

• init_file -> init_path

• design_file -> design_path

• structure -> deprecated: Providing structure=True on saving the network is not required anymore, the network structure is exported automatically.

Note

The initialisation method and handling of design and offdesign calculations has been adjusted. In future, please specify the path to the folder, where your results have been saved, e.g.:

mynetwork.save('path/to/folder')
mynetwork.solve('offdesign', design_path='path/to/folder', init_path='path/to/folder')

### Testing#

• The examples in the docstrings are used as doctests.

• Component tests have been implemented.

• General tests for errors, printouts and fluid properties have been implemented.

• Benchmark test for a heat pump model (still to be improved, see inline comments).

• Testcoverage will be checked for every PR in the future!

See PR #52.

### Bug fixes#

• Adjusted network export and network import to work for grouped component properties and characteristic maps (PR #46).

• Redesigned pre- and postprocessing of component properties as some errors occoured before. Design parameters are now always gathered from the component .csv-file containing the design point information (saved design state of the network) (PR #50).

### Other changes#

• Improved calculation speed by swapping the CoolProp.CoolProp.PropsSI-calls with CoolProp.AbstractState calls (PR #49).

### Contributors#

• Francesco Witte

## v0.0.5 (October, 25, 2018)#

### New Features#

• added new component: motoric cogeneration unit (79a1177). An example is provided here.

• improved fluid property checks (8adc76c).

• added bus characteristics for modeling variable efficiencys (e.g. for generator, motor, boiler) (79a1177).

• isentropic efficiency characteristic for compressor linked to pressure ratio (85d317d).

• added volumetric flow specification (63db64d).

### Documentation#

• adapted documentation and (example code) in regard of new features.

• fixed some typos in documentation.

### Parameter renaming#

compressor - vigv -> igva (inlet guide vane angle)

simple heat exchanger - t_a -> Tamb (ambient temperature)

solar collector - t_a -> Tamb (ambient temperature)

### Bug fixes#

• fixed a bug in the function v_mix_ph (specific volume for gas mixtures) (d487381).

• fixed compressor derivatives for usage with custom variables (71cae48).

• removed unecessary loop (187505b).

• fixed attribute handling in subsystem: condenser with subcooler (2c926bb).

### Other changes#

• remodeled the characteristic map for compressors: if not specified, igva is assumed to be 0° (2425a77).

• redesigned the printouts for component parameters (9465be6, b2c0897, cbbc1a1, 1e55e36, 2e795c2)

• custom variables are available for (977a5be):
• turbomachines,

• vessels,

• simple heat exchangers (as well as pipes and solar collctors) and

• cogeneration unit.

### Contributors#

• Francesco Witte

• Paul Hansen

## v0.0.4 (September, 2018)#

### New Features#

• added new component: solar collector (b5990e1).

• added a printlevel property for the network and improved the printouts in the calculation process (44d9f30).

• improved convergence speed (9cc1d8f)

• improved fluid initialisation (20ae7b3)

### Documentation#

• improved the online-documentation with new structure and new examples (fa5e7ca, 6ef4d99). You will find the new examples in this section.

• fixed some typos in different modules and the online-documentation

### Bug fixes#

• fixed bugs in subsystem logic (initialisation, set_attr, set_conns, 321308f)

• fixed bugs in bus.set_attr (2294261), h_mix_pQ (eac08cc), starting values for fluid composition (e3b2a77, 8f92821), given heat flow of heat exchangers (4b24651)

### Contributors#

• Francesco Witte

## v0.0.3 (July 05, 2018)#

### Bug fixes#

• convergence stability improvements for combustion chamber, fixes in the equations and derivatives (2c396f0, 59e3879, 10b2887).

• fixes/improvements for the convergence control (6e8ea60, 43e8ee1).

• fixed vapour quality specification (ec3865d).

• added missing get_attr method for class characteristics (13cf730).

• added bus functions to every component (41e9f2b, 7fefc59).

### Contributors#

• Francesco Witte

• Shuang Chen

Thanks to Shuang and Haibing from the UFZ for implementing the hazen-williams equation!

## v0.0.2 (April 07, 2018)#

### New Features#

• Changed architecture of the variables and component parameters. Every parameter is now a data container, giving the user more flexibility (e.g. specifiying a unit) and facilitating future development.

• Changed architecture of fluid property function calls to make custom fluids or custom fluid property functions available.

• Added custom fluid class to generate fluid properties from given fluid mixture.

• Added generic component characteristics for turbine isentropic efficiency and cone law as well as for the heat exchangers heat transfer coefficient. On top, the user may use own values for the characteristic lines.

• Added val_SI to data container for component properties for future development.

### Documentation#

• Added documentation on how to handle data containers for variables and parameters.

• Added an example for combustion chamber usage.

### Bug fixes#

• Adjusted the generic pump characteristics to cause less instabilites and adjusted function parameters according to KSB.

• Fixed bug in combustion chamber’s thermal input equation.

• Fixed parameters for numerical calculation of derivatives.

• Fixed starting relaxation parameter.

### Other changes#

• Improved convergence stability for combustion chamber and heat exchanger.

### Contributors#

• Francesco Witte

## v0.0.1 (March 08, 2018)#

First release.

### Contributors#

• Francesco Witte

Thanks to - Paul-Jonas Hansen and - Malte Fritz for adding the tutorial and a lot of testing and trouble-shooting!


text:
# Conditions for a homeomorphism

In my topology notes the definition is given as:

A function $f : X \rightarrow Y$ is said to be a homeomorphism if: $f$ is continuous, bijective, and moreover its inverse $f^{−1} : Y \rightarrow X$ is continuous.

My question is: Does the fact that $f$ has an inverse not already guarantee that $f$ is bijective?

• It guarantees its inverse, which does not mean it is necessarily continuous. Feb 9 '16 at 19:06
• If you'd define "$f$ is continuous and its inverse ..." your audience would interrupt you and shout "What inverse? Do you mean $f$ is in fact bijective? Or injective and you mean left inverse? Or surjective and you mean right inverse? But those are not even unique in general! Help, I'm lost!". You might shorten to "$f$ is continuous and has a continuous two-sided inverse". Or, more leaning towards category theory: "$f$ is continuous and there exists continuous $g\colon Y\to X$ with $f\circ g=\operatorname{id}_Y$ and $g\circ f=\operatorname{id}_X$." Feb 9 '16 at 19:08

The fact that $f$ is bijective ensures that $f^{-1}$ is a valid function from $Y$ to $X$. We now want both $f$ and $f^{-1}$ to be continuous, and the latter is not automatic from the former (consider the identity between $X$ in the discrete topology to $X$ in a non-discrete topology, e.g.). So we demand them separately.
We could just say $f$ and $f^{-1}$ are both continuous, but then we'd be implicitly assuming the bijectivity of $f$ by just "using" a function $f^{-1}$. It's better to be explicit here, and state the bijectiveness separately. Hence the order: $f$ continuous, bijective (so that $f^{-1}$ is a valid function!) and finally this function $f^{-1}: Y \rightarrow X$ is also continuous.

format: plain


text:
# Can you tie in 3D Tic-Tac-Toe?

In 3D Tic-Tac-Toe, there are 3 2D planes, each 3x3 in size, stacked on top of each other. A winning line can go through each of the layers (in addition to the standard winning lines of normal Tic-Tac-Toe). If two players are playing with the standard rules, how could they achieve a tie?

• we only consider only 3 2S layers like seperate ttt or need to think it is actually 3D ttt with all possible 2d layers? – Oray Aug 27 '18 at 4:07
• Can you confirm if any three-in-a-row wins or just in-layer and straight-down ones? – Jonathan Allan Aug 27 '18 at 6:54
• This is not possible. If it is, could you please give a hint? – Holyprogrammer Aug 27 '18 at 10:40

It is not possible.

There are only 3 essentially different ways have a filled a layer without three in a row:

  X O X    O X X    O X O
X X O    X O O    X O X
O X O    X O X    X O X

Each of these can of course be rotated/reflected, or have O and X interchanged. It is not possible to have 6 pieces of one player and 3 of the other without a winning line.

Count how many rows/column in these patterns alternate (i.e. are XOX or OXO). All three filling patterns have exactly two such rows/columns on the outside, and only the third pattern has an additional alternating row/column in the middle.

If you fill the middle layer of the cube, the middle row of two of the faces on the side of the cube are alternating. This forces those two side faces of the cube to use the third filling pattern. Those two faces can be opposite or adjacent, but either way it leads to problems. In both cases it makes two edges of the top and bottom layers alternating, which means the other two edges in each of those layers are not alternating. The other two side faces of the cube then have at least 3 or 4 edges that are not alternating, and so cannot be filled with one of the patterns.

Therefore it is impossible to fill the cube without having 3 in a row.

• This assumes that the players fill out each tic-tac-toe board one after another, but that wasn't specified. There can also be a layer with more Xs than Os if there is another layer with more Os than Xs – b a Aug 27 '18 at 9:43
• @ba No it doesn't. For a game to be a draw, the cube will be completely filled at the end of the game. I am just trying to find what that filled cube looks like. It also just happens to be the case that there is no filling pattern with 6X and 3O without a winning line, so they must all be 5X/4O or 4X/5O. – Jaap Scherphuis Aug 27 '18 at 9:51


text:
# dgl.to_homogeneous¶

dgl.to_homogeneous(G, ndata=None, edata=None)[source]

Convert a heterogeneous graph to a homogeneous graph and return.

Node and edge types of the input graph are stored as the dgl.NTYPE and dgl.ETYPE features in the returned graph. Each feature is an integer representing the type id, determined by the DGLGraph.get_ntype_id() and DGLGraph.get_etype_id() methods.

The function also stores the original node/edge IDs as the dgl.NID and dgl.EID features in the returned graph.

Parameters
• G (DGLGraph) – The heterogeneous graph.

• ndata (list[str], optional) – The node features to combine across all node types. For each feature feat in ndata, it concatenates G.nodes[T].data[feat] across all node types T. As a result, the feature feat of all node types should have the same shape and data type. By default, the returned graph will not have any node features.

• edata (list[str], optional) – The edge features to combine across all edge types. For each feature feat in edata, it concatenates G.edges[T].data[feat] across all edge types T. As a result, the feature feat of all edge types should have the same shape and data type. By default, the returned graph will not have any edge features.

Returns

A homogeneous graph.

Return type

DGLGraph

Examples

The following example uses PyTorch backend.

>>> import dgl
>>> import torch

>>> hg = dgl.heterograph({
...     ('user', 'follows', 'user'): ([0, 1], [1, 2]),
...     ('developer', 'develops', 'game'): ([0, 1], [0, 1])
...     })
>>> hg.nodes['user'].data['h'] = torch.ones(3, 1)
>>> hg.nodes['developer'].data['h'] = torch.zeros(2, 1)
>>> hg.nodes['game'].data['h'] = torch.ones(2, 1)
>>> g = dgl.to_homogeneous(hg)
>>> # The first three nodes are for 'user', the next two are for 'developer',
>>> # and the last two are for 'game'
>>> g.ndata
{'_TYPE': tensor([0, 0, 0, 1, 1, 2, 2]), '_ID': tensor([0, 1, 2, 0, 1, 0, 1])}
>>> # The first two edges are for 'follows', and the next two are for 'develops' edges.
>>> g.edata
{'_TYPE': tensor([0, 0, 1, 1]), '_ID': tensor([0, 1, 0, 1])}

Combine feature ‘h’ across all node types in the conversion.

>>> g = dgl.to_homogeneous(hg, ndata=['h'])
>>> g.ndata['h']
tensor([[1.], [1.], [1.], [0.], [0.], [1.], [1.]])


text:
# How do we assess solubilities of chromates, and ammonium salts?

Chromates tend to be insoluble; ammonium salts, like alkali metal salts, tend to be soluble. Of course, there are exceptions. $\text{ammonium tetraphenyl borate}$ is known to be quite insoluble. I cannot offer a simple way to remember them. I would try to remember your chemistry practicals..........


text:
# Do multiplicative maps of matrices factor through determinants?

Given a map $f:M_n(k)\to k$ (with $k$ some field) such that $f(AB)=f(A)f(B)$ for all matrices $A$ and $B$, is it necessarily the case that $f$ factors through the determinant, i.e. does there exist a multiplicative map $g:k\to k$ such that $f=g\circ\det\,$? Are constraints on $k$ necessary?

A simple corollary would be that nonzero multiplicative maps on subgroups of the general linear group $GL_n(k)$ factor through multiplicative maps on the units $k^\times\to k^\times$.

Two definitions of $\det$ I'm aware of (written with our setting in mind):

• The unique alternating mulilinear map (of column vectors in a matrix) sending $I$ to $1_k$.
• The trace of the map induced by $A$ on the $n$th exterior power $\mathrm{Alt}^nk^n$.

By Gaussian elemination, any multiplicative map $f$ from matrices to the base field is determined by its values on the matrices representing elementary row operations and upper triangular matrices.

One stumbling block is that it seems hard, in general, to fully characterize the multiplicative maps on the base field $k$. With a finite field it would just be integer powers and the zero map, but with the reals you get all (positive) real powers too, and some funky stuff may occur with other fields.

-
For a relatively wide range of fields $k$ and integers $n$ we have that $SL_n(k)$ is the commutator subgroup of $GL_n(k)$. Your mapping $f$ sends all the commutators to $1_k$, so given that the determinant distinguishes the cosets in $GL_n(k)/SL_n(k)$, the answer to your question seems to be YES, whenever $GL_n(k)'=SL_n(k)$. –  Jyrki Lahtonen Jun 15 '12 at 7:41
@JyrkiLahtonen It's always the case that $GL'=SL$, right? A nonzero multiplicative map $GL\to k$ descends to a homomorphism $GL/SL\to k^\times$, and $\det$ descends to an isomorphism $GL/SL\cong k^\times$, hence the $f$ will factor through $\det$, so that takes care of that. How do we extend this to all of $M_n$ - Zariski topology maybe (which I know next to nothing about)? –  anon Jun 15 '12 at 7:50
No, it's not always true that $SL$ is the commutator subgroup of $GL$. For example, if $k=\mathbb{F}_2$, we have that $SL_2(k)=GL_2(k)\simeq S_3$, but $S_3$ is not its own commutator subgroup. –  Jyrki Lahtonen Jun 15 '12 at 7:53
Ah I see. $SL=\mathrm{ker}\,\det$ and in general $GL'\subseteq SL$. –  anon Jun 15 '12 at 7:56
Extending the argument to singular matrices is tricky, but might work. Aren't all the rank $n-1$ matrices in the same orbit of $GL_n(k)$? So if $f$ takes a non-zero value on one of them, it will do so on all of them. But we get lower rank matrices as products of diagonal rank $n-1$ matrices and can keep going, so $f(A)\neq0$ for all $A$. But if $f(\mathrm{diag}(1,1,\ldots,1,0))\neq0$, then we run into a well-definedness problem, because we can multiply that matrix with $\mathrm{diag}(1,1,\ldots,1,x)$ without changing the product. It seems to me that then $f$ has to be constant $=1$??? –  Jyrki Lahtonen Jun 15 '12 at 8:30
Your mapping $f$ sends all the commutators to $1_k$, so given that the determinant distinguishes the cosets in $GL_n(k)/SL_n(k)$, the answer to your question seems to be YES, whenever $GL_n(k)'=SL_n(k)$, and we restrict the domain of $f$ to invertible matrices.
Lemma in N. Jacobson, Basic Algebra I, p. 377, tells us that $SL_n(k)$ is its own commutator subgroup (and obviously then also equal to $GL_n(k)'$) unless $n=2$ and $|k|=2$ or $3$. In the case $n=2$, $k=\mathbb{F}_2$ we have that $GL_2(k)=SL_2(k)\simeq S_3$ meaning that $GL_2(k)'$ is an index two subgroup of $SL_2(k)$. Using the ideas of the proof of this result it is easy to see that in the case $k=\mathbb{F}_3$ we do get that $GL_2(k)'=SL_2(k)$ (but $SL_2(k)$ is not its own commutator subgroup).
So we know that the restriction of your mapping $f$ to $GL_n(k)$ must factor via the determinant except possibly in the case $n=2,k=\mathbb{F}_2$.
I had a vague recollection that the list of exceptions to $GL_n(k)'=SL_n(k)$ is finite, but had to look it up. Sorry about that. –  Jyrki Lahtonen Jun 15 '12 at 8:11
Even given the failure of the commutator argument in the case $n=2$, $k=\mathbb{F}_2$ it is difficult to see, how we could get functions other than the determinant. This is because an index two subgroup must be mapped to 1, but the field $k$ has no elements of order 2 :-) –  Jyrki Lahtonen Jun 15 '12 at 8:33


text:
#### 3.3.1 Class and package structure

A class file or package file typically has four parts.

1. In the identification part, the file says that it is a LaTeX package or class and describes itself, using the \NeedsTeXFormat and \ProvidesClass or \ProvidesPackage commands.
2. The preliminary declarations part declares some commands and can also load other files. Usually these commands will be those needed for the code used in the next part. For example, an smcmemo class might be called with an option to read in a file with a list of people for the to-head, as \documentclass[mathto]{smcmemo}, and therefore needs to define a command \newcommand{\setto}[1]{\def\@tolist{#1}} used in that file.
3. In the handle options part the class or package declares and processes its options. Class options allow a user to start their document as \documentclass[option list]{class name}, to modify the behavior of the class. An example is when you declare \documentclass[11pt]{article} to set the default document font size.
4. Finally, in the more declarations part the class or package usually does most of its work: declaring new variables, commands and fonts, and loading other files.

Here is a starting class file, which should be saved as stub.cls where LaTeX can find it, for example in the same directory as the .tex file.

\NeedsTeXFormat{LaTeX2e}
\ProvidesClass{stub}[2017/07/06 stub to start building classes from]
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}
\ProcessOptions\relax
\LoadClass{article}

It identifies itself, handles the class options via the default of passing them all to the article class, and then loads the article class to provide the basis for this class’s code.

For more, see the official guide for class and package writers, the Class Guide, at https://www.latex-project.org/help/documentation/clsguide.pdf (much of the descriptions here derive from this document), or the tutorial https://www.tug.org/TUGboat/tb26-3/tb84heff.pdf.


text:
## A canonical polynomial for the volume of a polyhedron.(English. Russian original)Zbl 0941.52009

Russ. Math. Surv. 54, No. 2, 430-431 (1999); translation from Usp. Mat. Nauk 54, No. 2, 165-166 (1999).
Let there be given a polyhedron in $$\mathbb R^3,$$ homeomorphic to the sphere, with triangular faces and $$n$$ vertices, numbered from 1 to n in some order. Let $$x =\{x_1,y_1,z_1,x_2,y_2,z_2,\dots,x_n,y_n,z_n\}$$ be the coordinates of the vertices, written out in numerical order, and let $$l=\{l_1,\dots ,l_e\}$$ be the squares of the lengths of the edges, numbered in some order from 1 to $$e = 3n - 6$$; let $$V$$ be the volume, and let $$l(x)$$ and $$V(x)$$ the expressions for $$l$$ and $$V$$ in terms of the coordinates.
It is known [I. Kh. Sabitov, Fundam. Prikl. Mat. 2, No. 4, 1235-1246 (1996; Zbl 0904.52002) (Russian)], that for any polyhedron in $$\mathbb R^3$$ there is a polynomial $$P_0 \in \mathbb Q[l][V]$$ such that the leading coefficient LC$$(P_0) = 1$$ (that is, $$P_0$$ has the form $$V^N+ \sim_{n<N} p_n(l)V^n,$$ where the $$p_n(l)$$ are polynomials in $$l$$) and $$P_0(l(x), V(x)) = 0.$$ In particular, this polynomial enables us, in terms of the known metric of the polyhedron, to obtain a finite set of numbers, the roots of the polynomial, that contains the values of the volumes of all realizations (including the complex ones) of the metric of this polyhedron. But the algorithm for constructing this polynomial does not produce a unique result and many such polynomials can be constructed by it; also, it certainly gives a polynomial of much higher degree than is actually necessary. The authors give a unique method for constructing the required polynomial of minimum degree.
Let $$S$$ be the set of polynomials $$Q \in \mathbb Q[l][V]$$ such that $$Q(l(x), V(x)) = 0,$$ not necessarily having leading coefficient 1. The following theorem gives some properties of this set. Let $$d$$ be the smallest (non-zero) degree of the polynomials in $$S.$$ Then among the polynomials of degree $$d$$ in $$S$$ there is a polynomial $$Q_0$$ with LC$$(Q_0) = 1.$$ The polynomial $$Q_0$$ divides all the polynomials in $$S.$$ Such a polynomial $$Q_0$$ is unique.

### MSC:

 52B10 Three-dimensional polytopes 51M25 Length, area and volume in real or complex geometry

Zbl 0904.52002
Full Text:


text:
## CryptoDB

### Paper: A Built-in Decisional Function and Security Proof of ID-based Key Agreement Protocols from Pairings

Authors: L. Chen Z. Cheng Nigel P. Smart URL: http://eprint.iacr.org/2006/160 Search ePrint Search Google In recent years, a large number of identity-based key agreement protocols from pairings have been proposed. Some of them are elegant and practical. However, the security of this type of protocols has been surprisingly hard to prove. The main issue is that a simulator is not able to deal with reveal queries, because it requires solving either a computational problem or a decisional problem, both of which are generally believed to be hard (i.e., computationally infeasible). The best solution of security proof published so far uses the gap assumption, which means assuming that the existence of a decisional oracle does not change the hardness of the corresponding computational problem. The disadvantage of using this solution to prove the security for this type of protocols is that such decisional oracles, on which the security proof relies, cannot be performed by any polynomial time algorithm in the real world, because of the hardness of the decisional problem. In this paper we present a method incorporating a built-in decisional function in this type of protocols. The function transfers a hard decisional problem in the proof to an easy decisional problem. We then discuss the resulting efficiency of the schemes and the relevant security reductions in the context of different pairings one can use.
##### BibTeX
@misc{eprint-2006-21653,
title={A Built-in Decisional Function and Security Proof of ID-based Key Agreement Protocols from Pairings},
booktitle={IACR Eprint archive},
keywords={public-key cryptography / ID Based Key Agreement Protocols},
url={http://eprint.iacr.org/2006/160},
note={ nigel@cs.bris.ac.uk 13272 received 28 Apr 2006, withdrawn 4 May 2006},
author={L. Chen and Z. Cheng and Nigel P. Smart},
year=2006
}


text:
## a question regarding convex function.

let f:(a,b)-> a differentiable function, f is a convex function iff for every x in (a,b) the tangent line to f's graph in x is below f.

i tried it this way:
suppose f is a convex function, then for every 0<d<1 and every s,t in (a,b), f(dt+(1-d)s)<=df(t)+(1-d)f(s), now the tangent line in lets say x0 is
g(x)=f'(x0)(x-x0)+g(x0)
if s>t and t<x<s then g(t)=f'(x0)(t-x0)+g(x0) g(s)=f'(x0)(s-x0)+g(x0)
f'(x0)=[g(t)-g(s)]/(t-s)
i need to prove that g(x)<=f(x)
now if x=dt+(1-d)s then g(dt+(1-d)s)=f'(x0)(dt+(1-d)s-x0)+g(x0)

how do i proceed from here?, thanks.

 PhysOrg.com science news on PhysOrg.com >> Hong Kong launches first electric taxis>> Morocco to harness the wind in energy hunt>> Galaxy's Ring of Fire
 Recognitions: Science Advisor Well, the first thing is that g(x) = f'(x0)(x-x0)+f(x0). Your equation for g is correct but hard to work with. I'm not sure how to approach this. If you could show that f is _locally_ greater than its tangent line, then it is not hard to show that it is globally greater.
 Recognitions: Homework Help Does it help to know that a line is just convex, in the sense that the inequality you mentioned is actually an equality for all d, t, and s?

## a question regarding convex function.

more questions regarding convex function:
1) let f:[a,b]->R be a convex function, prove that if there exists c in [a,b] such f(a)=f(b)=f(c) then f is constant.
2) let g:(0,infinity)->R be a convex function ,
lim g(x)<infinity
x->infinity
prove that g(x) monotonic decreasing.

what I did is as follows:
1) for every 0<d<1 f(c)=df(a)+(1-d)f(b)>=f(da+(1-d)b)
let c=(1-d)a+db then f(c)=f((1-d)a+db)<=(1-d)f(a)+df(b)=f(c)
f(da+(1-d)b)<=df(a)+(1-d)f(b)=f(c)=f(1-d)a+db)<=(1-d)f(a)+df(b)=f(c)
how do conclude from this that fis constant.
2) from what is given we can deduce that: g(x)<=M when M is the supremum of g(x), now we also have for x1>x2 and 0<d<1 g(dx2+(1-d)x1)<=dg(x2)+(1-d)g(x1) if we let M=dg(x2)+(1-d)g(x1) then g(x)<=dg(x2)+(1-d)g(x1)
if x=x1 then g(x1)<=g(x2) but also when x=x2 g(x2)<=g(x1)
so I reackon my approach is flawed so how do I fix it?

 Recognitions: Homework Help For the first one, assume some point d, say, between a and c, has f(d) not equal to f(a). Depending on whether it is greater or less, you can find points between which the function contradicts the convex assumption. (try drawing it) For the second, assume there is some x,y with x
 so is this proof correct? let y>x g(y)>=g(x) let c in (x,y) g'(c)=[g(y)-g(x)]/(y-x)>=0 let f(x) be the tangent line to g(x) in the point (c,g(c)) f(x)=g'(c)(x-c)+g(c) because g(x) is convex function, g(x)>=g'(c)(x-c)+g(c) therefore g(x) is not bounded above, and thus doesnt converge as x approaches infinity.
 Recognitions: Homework Help That looks about right, except it should be g(y)>g(x), not g(y)>=g(x). And maybe add one more step before the end. "Not bounded above" does not directly follow from "bounded below by f(x)," expecially if f(x) is constant as your proof curently allows (see my first point).
 but im not given in my second question that g is constant. so what should i add?, i thought that it suffices to say that g(x) is not bounded above to show that as x apparoaches infinity g(x) diverges.
 Recognitions: Homework Help A monotonically decreasing function satisfies f(x)>=f(y) whenever xa implies f(x)>b. Bounding something below by a function f(x) does not say it isn't bounded above unless you first prove something about f(x). Maybe I'm being picky, but I think you should show this step.
 so if i put x=c then f(c)=g(c), and for every M=g(c) when x>c then g(x)>=M will that suffice? btw, i know this epsilon delta definition, and i understand, that you're employing an ad absurdum proof but what i didn't understand is why did you say:"expecially if f(x) is constant as your proof curently allows " why my proof allows g (or as you say f(x)) to be constant? by the way the definition i know of monotonic decreasing, is if x>y then f(y)>f(x), this is why i assumed that x>y and f(x)>=f(y) (which is the negation of f(y)>f(x)).

Recognitions:
Homework Help
 Quote by loop quantum gravity so if i put x=c then f(c)=g(c), and for every M=g(c) when x>c then g(x)>=M will that suffice?
I have no idea what you're saying here.

 btw, i know this epsilon delta definition, and i understand, that you're employing an ad absurdum proof but what i didn't understand is why did you say:"expecially if f(x) is constant as your proof curently allows " why my proof allows g (or as you say f(x)) to be constant?
I'm referring to the following:

 let y>x g(y)>=g(x) let c in (x,y) g'(c)=[g(y)-g(x)]/(y-x)>=0 let f(x) be the tangent line to g(x) in the point (c,g(c)) f(x)=g'(c)(x-c)+g(c)
Here you use g(x) to refer to the original function, and f(x) to refer to the tangent line. Since g'(c) may be zero in this argument, f(x) may be constant, in which case g(x) may in fact be bounded above, even if it is bounded below by f(x).

 by the way the definition i know of monotonic decreasing, is if x>y then f(y)>f(x), this is why i assumed that x>y and f(x)>=f(y) (which is the negation of f(y)>f(x)).
"Monotonically decreasing" and "strictly monotonically decreasing" are different concepts. The authors of this question must mean the former, not the latter (which you are describing here), because the function f(x)=0 is (a) convex, (b) has a finite limit as x goes to infinity, and (c) not strictly monotonically decreasing , thus providing a counterexample to the statement you want to prove. However, f(x)=0 is monotonically decreasing, which is to say it satisfies the conditions I spelled out in my last post.

 [QUOTE=StatusX]I have no idea what you're saying here. [\QUOTE] what i wanted to say is, that we have g(x)>=f(x) when f(x) is the tangent line to g(x). if we put at the equation of f(x) x=c we get f(c)=g(c) and thus we have a number g(c) that when x>c then g(x)>=g(c). if it's not correct, then how would you find a number that for some other number when x is greater than it, also the function is greater than the previous number?

Recognitions:
Homework Help
 Quote by loop quantum gravity what i wanted to say is, that we have g(x)>=f(x) when f(x) is the tangent line to g(x). if we put at the equation of f(x) x=c we get f(c)=g(c) and thus we have a number g(c) that when x>c then g(x)>=g(c). if it's not correct, then how would you find a number that for some other number when x is greater than it, also the function is greater than the previous number?
From what you say in the second paragraph, you know that isn't correct, because you've only shown what you need to for one number, f(c). Maybe I've overcomplicated things. I'll explain what you need to do in english and let you translate it to math. You have a function that is bounded below by a line which has positive slope. It is easy to prove that the line is not bounded above. Thus the function cannot be bounded above.

 tell me if this is right: for every real number b, such that there exists x, which x>c then f(x)>f(c) (this we can conclude from our assumption), if we let f(c)>b, then we have that f(x) diverges, and thus not bounded above.
 Recognitions: Homework Help What is c here? Is it the point where the function has positive slope, as it was before? If so, remember: you only know it has positive slope at one point, so you can't just keep increasing f(c) so that it is greater than any given b. f(c) is fixed. All you need to do is prove that a line is not bounded above. For example, the line f(x)=2x is not bounded above because for any a we might pick, we can find a number b such that x>b implies f(x)>a, namely, by taking b>=a/2. Once you prove the tangent line, which you originally called f(x), is not bounded above, a simple argument shows that any function g(x) such that g(x)>=f(x) for all x (which your original function has been proven to satisfy) must also be unbounded above. You should not need to reference the point x=c or f(c) again. And please make an earnest attempt to solve the problem. You have more than enough information. I'll only help you again if you have a question that you can't answer even after trying very hard to figure it out yourself. That's the only way you'll learn anything.
 ok, if we let x>b then for every a which b>=(a/g'(c)+c-g(c)/g'(c)) we have that f(x)>f(b)>=f(a/g'(c)+c-g(c)/g'(c))=a. if this is right, it's quite messy.
 Recognitions: Homework Help That's the idea. It might actually be easier and neater to first prove a more general result, like that all lines of positive slope are not bounded above, or that if one function is not bounded above, any function differing from it by an additive constant is also not bounded above. Then you can apply this result to your example. But what you have will suffice.


text:
# “Honest” introductory real analysis book

I was asked if I could suggest an "honest" introductory real analysis book, where "honest" means:

• with every single theorem proved (that is, no "left to the reader" or "you can easily see");
• with every single problem properly solved (that is, solved in a formal (exam-like) way).

I've studied using Rudin mostly and I liked it, but it really doesn't fit the description, so I don't know what book I should suggest. Do you have any recommendations?

Update: I need to clarify that my friend has just started to study real analysis and the course starts from the very basics, deals with real valued functions of one variable, but introduces topological concepts and metric spaces too.

• are you looking for an introduction to elementary real analysis (i.e., real valued functions of a single real variable) or an introduction to analysis a la Rudin, assuming the elementary things are known and aiming at topology, metric space theory etc.? – Ittay Weiss Nov 30 '14 at 20:56
• It is strange, but an honest introduction to analysis is Spivak's Calculus. – Artem Nov 30 '14 at 23:40
• I can't help but remark/claim that your friend should not really study from such a thing, etc. That is, carrying out every detail, and doing so "properly" (code for exaggerated-formal) is substantially misguided. – paul garrett Dec 1 '14 at 0:07
• @paulgarrett Could you please elaborate on that a bit? – littleO Dec 1 '14 at 1:14
• @littleO, to invest one's time and energy in the proposed fashion is, to my mind, suboptimal in at least two ways. First, surely one has caught on to the general pattern of the low-level details after a certain number of example-proofs, without having to continue and see every other idea accompanied by all those low-level details... which tend to swamp the main idea. Second, getting into the habit of conceiving of the activity of mathematics as essentially involving writing out all possible details, rather than choosing the most-relevant, critical details, is simply bad practice. – paul garrett Dec 1 '14 at 13:56

Get two volumes of Zorich.

• I accept this answer because these are the books that my friend finded the most suited for the purpose. However, I would like to emphasize that I personally appreciate every suggestion given here and that some of the books mentioned will likely prove useful for me too as a complement to Rudin. Once again, thank you everyone! – Dal Dec 3 '14 at 21:53

Possibly Abbott, Understanding Analysis

A bit of self publicity, but the reason that A Primer on Hilbert Space Theory was written is precisely to give what you refer to as an 'honest' introduction to the foundations of analysis.

Edit: OP's comment below clarifies this book is not at the intended introductory level.

• -1: This is a very poor self publicity. This book has got nothing to do with introductory real analysis of relevance to the student. – Adhvaitha Nov 30 '14 at 20:46
• The OP wants an introductory real analysis text, by which he needs some text that talks about 1) Completeness of $\mathbb{R}$ 2) Sequences and series 3) Continuity 4) Derivatives 5) Integral (Riemann) 6) Some basic topology on $\mathbb{R}$ Your book at best can be regarded as an "introductory" functional analysis book. – Adhvaitha Nov 30 '14 at 20:52
• @Adhvaitha your negative comment appeared within a minute of the appearance of the answer, which means (as you obviously did not read the book) that you had time to just see the title. If you had looked at the TOC you would have seen that the first three chapters are, respectively, thorough introductions to linear spaces, topological spaces, and metric spaces. The style is very much what OP is looking for (i.e., very detailed proofs with little left for the reader). It covers completeness, topology, sequences, continuity. Rudin is given as benchmark. – Ittay Weiss Nov 30 '14 at 20:54
• My negative comment as you can see from the time stamp appeared $5$ minutes after your answer. An introductory real analysis text (by which I mean analysis on $\mathbb{R}$ instead of $\mathbb{R}^n$ or any other space) should first study the properties of $\mathbb{R}$ in detail, instead of topological spaces, linear spaces etc. It needs to first develop $\mathbb{R}$ and discuss all the topics such as convergence, continuity, derivative, etc. in the context of $\mathbb{R}$. A student reading real analysis for the first time should not be thrown away by premature abstraction. – Adhvaitha Nov 30 '14 at 21:00
• @IttayWeiss Please, keep the answer here, because -- judging from the sample pages on linear spaces -- the book seems well-explained and therefore the parts on metric and topological spaces may prove useful for my friend (and to me too). – Dal Nov 30 '14 at 21:50

I have had the pleasure to teach introductory real analysis from couple of excellent texts, which I would also recommend.

• +1: Although Bartle/Sherbert do make some "exercise to the reader" and "obvious" statements, it is a good text. – Clarinetist Dec 1 '14 at 1:26
• Ross's book frequently appeals to the reader's naive understanding of calculus. Not sure if this is customary, but it might not be what OP has in mind in terms of "honest." Not sure, but definitely not a bad book - I used it in my first exposure. – Alfred Yerger Dec 1 '14 at 6:46

Bartle's Introduction to Real Analysis has a small number of "left to the reader" proofs, from I have seen so far.

Advanced Calculus by Patrick M. Fitzpatrick is a great text that starts from the very basics and goes up through point-set topology and metric spaces.

It starts with field axioms and builds from there so it doesn't "cheat" in that regard (edit: just to clarify, this means almost NO proofs are "left to the reader," the only exceptions being very small special cases that are then presented in exercises), but it doesn't contain solutions--I think you'd be hard pressed to find a textbook at that level that had complete solutions to every single problem. However, it's popular enough that most of the solutions can be found on this site or elsewhere on the internet.

Starting from general one-dimensional stuff and moving up to metric spaces in a single course seems like quite a task though.

• Patrick Fitzpatrick, nice name ^-^ – user153330 Feb 3 '16 at 22:56

For an introduction more 'foot on the ground' analysis I recommend Elementary Classical Analysis. It's a shame that the partial visualization is not available. But you will not regret in search for this book in the library of a good university.

See too Vector Calculus, Linear Algebra, and Differential Forms: A Unified Approach. By John Hubbard and Barbara Burke. More in Amazon site.

• I found the earlier version of Marsden's "Elementary classical analysis" very useful. – copper.hat Dec 2 '14 at 6:52

I used Rosenlicht's Introduction to Analysis in my real analysis course in undergrad. It's cheap and is a lot easier to digest than Rudin.

Terence Tao's Analysis I and Analysis II. These books are expanded and cleaned up versions of lecture notes which you can find here and here.

Yet Another Introduction to Analysis by Bryant is my favourite. It probably doesn't meet all the criteria you listed. However, it is the most intuitive first book on the topic I know, and once you have read it, other analysis books become much easier.

• Hey, you're the author of Proof Patterns! I loved your book. It's a really unique exposition to proofs and proof methods! – Billy Rubina Jul 3 '17 at 6:51
• glad you liked it -- any publicity you can give to it would be appreciated! – Mark Joshi Jul 3 '17 at 14:31