The layout of the library was chosen carefully in the purpose of reuse-ability by applicants as well as expand-ability by model developers. The Basics package contains supporting classes like functions, units, blocks, media records, data tables, icons, and interfaces. Single components, e.g. electrical machines, pumps, and pipes, are structured within the Components package. These first two packages are meant to be used and modified by advanced users and developers only, whereas the remaining packages are meant for users that want to build up energy systems in order to examine different scenarios.

These packages are named after the four participating groups in the energy supply system: producer, consumer, grid, and storage. Within the Producer package there are small and large, conventional and renewable plants converting primary energy into electric work, heat or both. The Consumer package comprises models of electric power and thermal power loads for households, commercial buildings, industry as well as for bigger areas like city districts or whole cities. The package Grid is composed of electric, heat, and gas distribution elements. Within the Storage package there are different power-to-power (e.g. pumped hydro storage), heat-to-heat (e.g. sensible water storage tanks), gas-to-gas (e.g. caverns), as well as power-to-heat and power-to-gas converters. The last package Examples contains examples for the different system models in general and for the examined system of the city of Hamburg. These examples allow the users to understand the usage of components and the scope of application of the library.

Test models

Most models in the TransiEnt Library have an associated test model with minimum boundary conditions that enable a simulation of the model. These are named after the tested component and are located in a package named Check, e.g. ActivePowerGenerator and Check/CheckActivePowerGenerator. Some of these testers include a nested function with the name plotResult() which can be execute after the simulation and plot striking results illustrating the level of detail and behavior of the component.


The Modelica standard library defines the most important elementary connectors in various domains. However, the TransiEnt library defines two alternative connectors: one for fluids and one for electric terminals. The fluid interface fluidPort is taken from the ClaRa library - since most basic components (e.g. pipes for the heating grids) are used and extended from there. The medium model in the connector is an extension of the TILMedia class BaseVLEFluid. For real fluid behavior this type of medium class is favored. For ideal gas behavior (e.g. assumed for exhaust gas), the IdealGasEnthPort and IdealGasTempPort can be used which contain medium models based on the TILMedia BaseGas definition.

The mainly used electric interface ActivePowerPort has two variables: active power and frequency. Most of the electric models in the coupled energy system models use this interface, since it is sufficient for surveys that do not consider voltage stability, load flow calculations or non-symmetrical three phase systems. Alternatively the ApparentPowerPort can be used which adds voltage and reactive power.

The TransiEnt Library provides adapters which allow the user to connect models from the Modelica Standard Library to system models within TransiEnt, e.g. in TestEPP_to_QS the connection of MSL.Quasistationary components is illustrated.


Sign conventions

The sign conventions in the TransiEnt Library follow the consumer side convention: In consumers the flow variables are positive and in producers the flow variables are negative. If setpoints are passed to the models, they are supposed to have the same sign as the flow variable in the connector. For example a power plant model gets negative setpoints and has a negative power flow in its connector. Storage models get positive values for loading (increase of the state of charge). These conventions are illustrated in the picture below.

Level of detail

The TransiEnt library is intended to contain models at different levels of detail. It is mainly based on two criteria:

1. Purpose of model. In which simulation context will the model be used? What questions and physical effects shall be analyzed with the model?

2. Applicability of model. What are the main assumptions the model is based on? Are there some structural limitations?

Some models are named in a way that show the level of detail with respect to a spatial discretization. The following suffixes are used

Generated at 2024-07-24T18:15:57Z by OpenModelicaOpenModelica 1.23.1 using GenerateDoc.mos