About eELib

The models in eELib - like other models too - represent the real processes of existing components in a quasi-stationary / quasi-dynamic approach under the assumption of simplifications. The implementations of the eELib hold some characteristics, that will shortly be explained here.

General Setup

To start a simulation, one has to set up a scenario-file that should look like the test scenarios in the examples folder. There, one has to set up the models to be used and how to connect them. Data for the models has to additionally be provided.

Folder Structure

The model library is in a public Gitlab-Repository.

This is to give an overview of where different parts of the eELib are stored:

• docs : Files for the documentation with AutodocSphinx into the GitLab Pages style. Documentation is stored in .rst files within the source subfolder.

• eelib : This stores the main part of the elenia Energy Library, as it contains the models and all other functionalities.

  • core : Here all of the models are stored. This is divided into the components (like PV system or electric vehicle), control models (like energy management system), grid models (like grid control) and market models (like intraday market).

  • data : This contains all models that are “just” retrieving input data (like a simple csv-reader). It also includes the functionalities for simulation data to be collected and assessed.

  • utils : Contains helper functions and classes.

    • eval : Here the functionalities for evaluating and plotting/presenting outputs of simulations are stored, mostly in accessible and modifiable python scripts or jupyter notebooks.

  • testing : Contains all of the testing for the models and the whole library.

• examples : This folder gives data and scripts for various test scenarios and should provide an overview of how the eELib can be used. Data is stored in the data which also contains the simulations results.

The highest folder also contains various files that are used for setup of the environment and gitlab communication.

Familiarize with the folder structure of the eElib package by exploring the API Reference.

Plug-and-Play Style

The programming of the models should be implemented in such a way that it can also be used in real-world applications without any adjustments. This ensures that, for example, in the case of changed simulation scenarios or also in laboratory investigations, the same source code can simply be applied within the framework of “plug-and-play”.

Coupling With mosaik

In order to make the above mentioned investigation cases possible, one needs to couple the different models of the library in scenarios to be created, e.g. a PV system with the energy management system (EMS). For this purpose, an orchestrator is to be used, which performs the exchange of data sets between models, calls the calculation of the individual models and controls the general model flow as well as the coupling with a database. mosaik is intended for these tasks. Certain input values are assumed, data sets are calculated internally and output data sets are issued. See the mosaik Doc Part for more information. The eELib should definetily be usable with other orchestrators of a simulation, but the explanations in this documentation are done for mosaik and its simulation orchestration. Additionally, the eELib provides simulators to its models that serve the prupose of APIs for a simulation with mosaik.

Event-Based Simulation

The computations within the eELib are executed in an event-based manner. This implies the process of a simulation to depend on the triggering of events. Independent of a step_size - the length of a simulation step in seconds - the process within one simulation step is executed by event triggering, as depicted in the following figure. To add to the explanation of mosaik, the execution of events depends on the triggering of such events. E.g. the simulation of a BSS is triggered by an EMS sending a power set value to the BSS. For this, mosaik knows about …

• … when each model has to be called for calculation.

• … which outputs for the models are send to which inputs for other models.

1. mosaik calls the calculation of the entities via the simulator

2. models calculate output with the already given input

3. simulator returns the time, when the models have to be calculated next

4. mosaik sends the output to a connected entity (e.g. the power generation of a PV system to the HEMS)

5. mosaik then calls the calculation of the next entity for which all inputs have been collected (this is done by means of the word “triggering”, so the finalized calculation of one entity triggers the calculation of another entity…)

This is done within a single timestep as long as data is send between the entities such that the renewed calculation of a model entity is triggered. mosaik calls the execution of the models in the way they are connected to each other and send values each way. If everything is finished for this timestep, mosaik advances to the next timestep and the simulation process carries on.

The implementation of the process within one simulation step can be better seen in the next figure. It is shown, that when a model is called, the inputs for the models are provided by mosaik and set by the simulator. Afterwards the models are stepped and ultimately the simulators are called to extract the (by mosaik requested) result outputs from the models.