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.

Folder Structure

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 devices (like PV system or electric vehicle), control models (like energy management system), grid models (for power flow calculation), forecasting, 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.

  • utilsContains helper functions and classes, exemplarily for running a simulation or

    evaluating and plotting/presenting outputs of simulations.

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

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

The highest folder also contains various files that are used for setup of the environment, gitlab communication, a README for information etc.

You can also 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 in a “plug-and-play” way.

Coupling With mosaik and Architecture of a Simulation

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 eELib docomentation part on mosaik 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.

The following graphic illustrates the architecture of a simulation and the usage of mosaik in it. For explanations to the terms used for the parties also have a look at the glossary. While the eELib provides implementations for the models and their simulators, mosaik is used for a simulation. Additionally a scenario script and data for the scenario (like parameterization of the model entities and linking of entities) have to be provided. Examples for these last two are provided within the eELib in an examples part.

The architecture of a simulation using mosaik with the eELib.

For a setup of a simulation, have a look at the following illustration. It depicts the physical and data connections between the different parts of the eELib.

The setup of a (grid) simulation with the eELib.

Event-Based Simulation

The computations within the eELib - using mosaik - 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.

The simulation process of event-based simulation.

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.