REVOL-E-TION

Resilient Electric Vehicle Optimization model for Local Energy TransitION

REVOL-E-TION is an energy system model toolbox designed to optimize integration of electric vehicle fleets into
local energy systems such as mini- and microgrids, company sites, apartment blocks or single homes and estimate
the resulting technoeconomic potentials in terms of costs and revenues within the energy (and optionally also the
mobility system). It is built as a wrapper on top of the oemof energy system model framework.

Created by

Philipp Rosner, M.Sc. and Brian Dietermann, M.Sc.
Institute of Automotive Technology
Department of Mobility Systems Engineering
TUM School of Engineering and Design
Technical University of Munich
philipp.rosner@tum.de
September 2nd, 2021

Contributors

Marcel Brödel, M.Sc. - Research Associate 01/2024-
David Eickholt, B.Sc. - Semester Thesis submitted 07/2021
Marcel Brödel, B.Sc. - Semester Thesis submitted 05/2022
Hannes Henglein, B.Sc. - Semester Thesis submitted 10/2022
Marc Alsina Planelles, B.Sc. - Master's Thesis submitted 10/2022
Juan Forero Yacaman - Bachelor's Thesis submitted 04/2023
Elisabeth Spiegl - Bachelor's Thesis submitted 06/2023
Alejandro Hernando Armengol, B.Sc. - Master's Thesis submitted 10/2023
Hannes Henglein, B.Sc. - Master's Thesis submitted 01/2024
Florian Melzig, B.Sc. - Master's Thesis submitted 10/2024
Florian Honeder, B.Sc. - Semester Thesis submitted 09/2025
Jan-Niklas Weghorn, B.Sc. - IDP submitted 09/2025
Jan-Niklas Weghorn, B.Sc. - Master's Thesis submitted 04/2026

Table of Contents

• Licensing
• Related publications
• Description
• Installation
• Basic Usage
• Common Problems & Troubleshooting
• General Terms & Definitions
• Scenario Input Parameters
• EV-Specific submodules
  • Discrete Event Simulation (DES)
  • A priori Power Scheduling
  • A Posteriori Aging Model (also available for StationaryBattery)
• Outputs

Licensing

REVOL-E-TION is licensed under the Apache 2.0 open source license.
The full license text can be found in the LICENSE file in the root directory of the repository.

Related publications

• P. Rosner and M. Lienkamp, "Unlocking the Joint Potential of Electric Mobility and Rural Electrification - A Concept for Improved Integration using Modular Batteries," 2022 IEEE PES/IAS PowerAfrica, Kigali, Rwanda, 2022, pp. 1-5, https://doi.org/10.1109/PowerAfrica53997.2022.9905305.
• P. Rosner, B. Dietermann, M. Brödel and M. Lienkamp, "REVOL-E-TION: A Flexible and Scalable Model to Optimally Integrate Bidirectional EV Fleets in Local Energy Systems", Poster, 2024 Vehicle2Grid Conference, Münster, Germany, 2024, https://doi.org/10.13140/RG.2.2.19632.16648
• P. Rosner, B. Dietermann (shared first authors), M. Brödel, A. Paper and M. Lienkamp, "REVOL-E-TION: A Flexible and Scalable Investment Optimization Toolbox for Local Energy Systems Incorporating Electric Vehicle Fleets", 2025, SoftwareX, https://doi.org/10.1016/j.softx.2025.102178
• B. Dietermann, P. Rosner, N. Nachtigall and M. Lienkamp, "Enabling Residential Electric Car-Sharing Models Through Optimum Local Energy System Integration: A Concept", 2025, 5th International Conference on Electrical, Computer, Communications and Mechatronics Engineering (ICECCME), https://doi.org/10.1109/ICECCME64568.2025.11277639

Description

REVOL-E-TION is a scalable generator for (mixed integer) linear energy system models of local energy systems with or without electric vehicle fleets.
It can be used to optimize component sizes and/or dispatch behavior of the system to achieve the least cost in the simulation timeframe.
Simulation results are later extrapolated and discounted to a project timeframe to estimate the technoeconomic potential of the system in the long run.
Please note that this split between simulation and extrapolation improves computational effort, but creates possibly unwanted incentives for the optimizer (e.g. preferring low initial cost but operationally expensive power sources), especially when sizing components.

REVOL-E-TION groups oemof components and buses into blocks representing real-world systems (e.g. a PV array) for easy application.
Electric vehicles (in fact, any mobile storage devices) as well as Internal Combustion Engine Vehicles are modeled individually as instances of class FleetUnit within a Fleet block.
Their behavior (i.e. when they depart and arrive again, how much energy they use in between and whether they can be charged externally) is described in a so-called log file.
Log files can be created using the integrated Discrete Event Simulation (DES), which is also capable of modeling range extension through mobile batteries as well as multiple use cases in different time frames (e.g. summer/winter) for the FleetUnits.

The following system diagram shows the basic structure including one example of each block class (blocks are indicated by dashed lines):

Installation

REVOL-E-TION is designed to run under Windows 11, Ubuntu 22.04 LTS and macOS 15 Sequoia.
While portability is generally built in, other operating systems are untested.

Step 1: Getting the source code

REVOL-E-TION is available on GitLab and can be cloned from there using

git clone https://gitlab.lrz.de/energysystemmodelling/revol-e-tion.git

Step 2: Install package and dependencies locally

Dependencies are listed in the pyproject.toml file in the root directory of the repository (where README.md and pyproject.toml are located).
There, three different groups are defined:

• The default group contains all dependencies required to run REVOL-E-TION.
• The 'dev' group contains additional dependencies required for development such as code formatting and linting tools.
• The 'tests' group contains additional dependencies required for testing such as pytest and coverage.

Depending on your use case, you can choose to install only the default dependencies (if you just want to run the package) or also the dev and tests dependencies (if you want to develop the package).
This manual describes the installation using three different package managers: uv or conda / pip.

a) uv

To install REVOL-E-TION using uv, navigate to the root directory of the repository in your terminal and execute the following command:

uv sync

This command installs the package in editable mode and all dependencies of the default group.
To install all additional dependency groups add --all-groups to the previous command or select the groups you want to install using --group <group_name>.

b) conda / pip

It is recommended to create and activate a clean virtual environment for the installation of REVOL-E-TION.

This can be done using conda:

conda create -n <name_of_virtual_environment> python=3.12
conda activate <name_of_virtual_environment>

or alternatively with a pip virtual environment using the following command:

python -m venv <path_to_virtual_environment>
source <path_to_virtual_environment>/bin/activate

Navigate to package's root directory in your terminal.
Then install the package and its dependencies using one of the following commands depending on the chosen mode of installation:

i. Standard Installation

This copies the package into your (virtual environment’s) site-packages directory:

pip install .

After pulling new changes from the repository, the package has to be reinstalled using the same command to take the changes into account.

ii. Editable Installation (recommended for development)

This links the package to your local source code, so any changes (you make or pulled from the repository) are immediately reflected without reinstalling:

pip install -e . --group dev --group tests

Use the editable mode if you plan to modify the code during development. The previous command also installs additional dependencies required for development and testing, which are not necessary for running the package but required for development.

Step 3: MILP Solver

REVOL-E-TION requires a Mixed Integer Linear Programming (MILP) solver (as does oemof).
Three solvers are supported, selected via --solver: cbc, gurobi and highs.
The open-source HiGHS solver requires no separate installation, as it is installed automatically as part of the package dependencies.
The open-source cbc solver works well, but has to be installed separately.
The proprietary Gurobi solver is recommended however, as it is faster in execution, especially for large problems and offers a free academic license.
If Gurobi is used, the version of Gurobi and the license file have to match. The python package gurobipy is NOT required to run REVOL-E-TION.
To ensure this get the version of both your Gurobi license and installation (grbgetkey --version).

Basic Usage

⚠️ Important ⚠️

When using REVOL-E-TION, all input data such as timeseries and the scenario file should be stored in a separate directory and not within the package's source code.
Do not store any custom files within the source code of the package.
This includes the example directory in particular.

1. Running REVOL-E-TION as package

REVOL-E-TION can be run using one of two terminal commands, given the correct virtual environment is activated:

1. Call to the main module: python -m revoletion <arguments> (best for local execution on host machine, e.g. through a run configuration in PyCharm)
2. Call to the entry point: revoletion <arguments> (best for remote execution on a server as it works irrespective of the current working directory as long as the correct environment is active)

The scenario file is a CSV table.
Its exact API is described in the section "Scenario Input Parameters".
A runnable example scenario file is provided in the example directory.
Some parameters in the scenario file reference to other files specified by file name, mostly for timeseries data.
These are searched within the input directory specified.

Furthermore, to describe the mapping of different timeframes defining behavior of Fleets (see below), modification of the mapper_timeframe_example.py code file might be necessary to fit the scenario as this is not simply and flexibly done in parameter files.
The filename of the modified file has to be given in the scenario file under the key filename_mapper and the file has to be placed in the input directory specified in --input.

Concerning computational effort, REVOL-E-TION relies heavily on single core computing power for each scenario and uses significant memory, especially in the 'go' strategy.
To avoid memory limitations, it is advised to limit the number of parallel scenarios to be executed using --n_processes depending on the available hardware.

To run the provided example project, execute the following command in the terminal:

cd PATH/TO/REVOL-E-TION_REPOSITORY/example/
revoletion -scn scenarios.csv

2. Running REVOL-E-TION in Python

REVOL-E-TION can also be used as a module in your own code.
An example notebook executing REVOL-E-TION from Python is provided in .revoletion/example/run_example.ipynb.

Common Problems & Troubleshooting

General Terms & Definitions

The following table details common terms occurring in further descriptions and the code:

Term	Description
Project	An application of REVOL-E-TION in a specific setting. All files (scenarios file, input data files, etc.) should be contained in a single directory. ./example is an example project.
Run	A single execution of REVOL-E-TION defined by a single scenario file (possibly containing multiple scenario definitions as columns). Common information and methods valid for all scenarios are defined in a SimulationRun object.
Scenario	A set of parameters (i.e. an energy system) to be simulated and/or optimized. It is defined by a column in the scenario file and optional some additional timeseries inputs.
Strategy	The (energy management) strategy to dispatch the energy system's blocks generally. REVOL-E-TION supports two strategies: "go" for single shot global optimization and "rh" for rolling horizon (i.e. time slotted myopic) optimization similar to Model Predictive Control (MPC). The former is a special case of the latter with just a single horizon. Component size optimization is only applicable in "go".
Horizon	A single optimization process by the solver, whether as the only one of the scenario ("go" strategy) or as a slice of the simulation timeframe ("rh" strategy). In the latter case, the total simulation time is split up into prediction horizons (each of which is represented in the code by a PredictionHorizon object) that are simulated consecutively. However, overlap between the horizons is necessary to ensure feasibility of dispatch. Therefore, only the first part of the prediction horizon (called control horizon) is actually used for overall result calculation, while the rest is discarded. The simulation timeframe is automatically split up into horizons as per the defined length of prediction and control horizons from the scenario file. See the following diagram for clarification:
Block	A set of oemof components representing a real-world system including necessary converters and buses. Each is represented by an instance of the Block parent class with further child classes. The blocks present in the energy system are defined in the scenario file as a dictionary, except for the core block (of class SystemCore) containing the AC and DC buses as well as the converter(s) inbetween them. Multiple instances of one block can coexist in a model. The possible types (i.e. Classes) are laid out in the following chapter.
Component	A component is an oemof element that is either a source, a sink, a bus, a converter or a storage.

Scenario Input Parameters

Scenarios are defined in a CSV file, the so-called scenario file.
This file can contain multiple scenarios, each of which is defined by a column in the file.
Each column then holds all required parameters for the scenario, which are structured by blocks, leading to the following formatting of the scenario file:

In the first row, 'Block' and 'Key' are fixed column names. All other column names define the names of distinct scenarios.
To ignore a scenario during the simulation process, add a '#' in front of the scenario's name.
The first column defines the name of the block to which the parameter in the second column applies.
This name is defined in the scenarios blocks parameter for all blocks except for the scenario itself and the SystemCore which have to be named 'scenario' and 'core', respectively.

Although the scenario itself is no block in REVOL-E-TION's code logic, it is treated as a block in the scenario file.
A scenario file starts with a header row containing the fixed column names 'Block' and 'Key', followed by the names of the scenarios as column names.
The first rows represent the parameters of the scenario itself, which are not block specific.
The block name for the scenario always is 'scenario'.
The 'scenario' section is followed by the parameters for each block present in the scenario.
To ensure scalability of the scenario file, the parameters of a block are only read in, if the block is present in the scenarios parameter blocks.
This allows to define scenarios with different blocks in the same scenario file.
In addition to the blocks defined in the blocks parameter of the scenario exactly one instance of class SystemCore is automatically created and named 'core'.
Although the SystemCore must not be specified in the blocks dict, its parameters have to be defined in the scenario file (block name: 'core').
Instances of type GridMarket and SubFleet are also not specified in the scenario's blocks parameter, but in the parameters of their parent classes GridConnection and Fleet, respectively.

Complex (multidimensional) parameters are mostly defined through links to other files (by filename) in the scenario file.
As all string values specified in the scenario definition file are converted to lower case, all files have to be named in lower case to be read in properly.
The following table specifies each parameter for each possible block class in the scenario file.
If and only if a block of a certain class exists within the scenario, these parameters are required and read in.
Therefore, not every scenario file contains all possible parameters.
An example scenario file is provided in the .revoletion/example directory.

A further explanation of each block and its parameters is given in the expandable boxes below.

Each run can contain multiple scenario objects.
A scenario object holds several parameters that are used by multiple blocks in the scenario.
After a successful optimization it also contains the aggregated techno-economic results such as energy throughput, costs, revenues as well as LCOE, NPC, and NPV.

Collection of central energy system components (AC and DC buses and the two unidirectional transformers between them).
This is present once and only once in every energy system defined in REVOL-E-TION under the name "core".
For pure AC or DC systems, the respective core cost and size parameters can be set to zero to have no effect on the result.

Undeferrable (i.e. inflexible) power demand such as households.

Photovoltaic array. Power potential is defined either using Solcast (pre-downloaded CSV file or API), PVGIS (pre-downloaded CSV file or API), or a timeseries CSV file.
Although the Solcast API requires an active subscription plan, there is a limited free plan for researchers.

Wind turbine. Power potential is defined either in a csv timeseries file or retrieved from PVSource data containing wind speed, which is then converted to power for a specific turbine height.
For the latter option, a PVSource block must exist.

Independently controllable power sources (e.g. fossil generator, hydro power plant) that is unlimited in energy.

Physical grid connection. A GridConnection instance requires one or multiple GridMarkets.

Virtual GridMarket connected to a specific physical GridConnection.

Stationary battery energy storage systems.
A posteriori aging (i.e. capacity reduction) estimation is possible and will be taken into the next horizon as a reduced available SOC range.
Storage modelling is done linearly without SOC or temperature based limits of charge or discharge power.

Fleet consisting of one or several SubFleets.

SubFleet consisting of initially identical FleetUnits (Electric Vehicle, Internal Combustion Engine Vehicle, Mobile Battery).
Behavior can either be given or generated within the integrated Discrete Event Simulation from stochastic behavioral parameters (use case definition in CSV file and python script with timeframe mapper)

EV-Specific submodules

Since REVOL-E-TION's main purpose is optimum EV integration, this is where focus lies in modeling detail, resulting in the DES and a priori power scheduling submodules.
The following sections give more detail on these submodules:

Discrete Event Simulation (DES)

The DES takes stochastically defined mobility or energy demand in multiple use cases and timeframes, samples an actual demand and assigns it to a Fleet (more specifically to the individual FleetUnit within it) in a first-come-first-serve approach.
This enables to model the mobility/energy demand independently of the (Sub)Fleet's size.
However, the DES is run a priori to the dispatch/sizing optimization, so no consideration of whether the resulting FleetUnit dispatch is beneficial to the energy system is taken and limitations through battery aging and/or other limitations have to be covered by safety margins in dispatch to achieve a feasible solution to the energy system's optimization problem.
Through the sampling, the DES also makes REVOL-E-TION outputs non-deterministic once it is activated even though the actual core optimization is deterministic.
A run can be made reproducible by writing out its dispatch events and feeding them back in through the 'events' data source, see "Dispatch events and the time based log" below.
The DES is run separately for every scenario in a simulation run, but only once per scenario, as some Fleets might be linked and can therefore not be simulated independently.
It is built on the simpy library and is implemented in the dispatch.py file.
A modification is made to simpy to enable processes to require multiple resources at once, which is necessary for mobile battery use cases requiring high energy.

The core element of the DES is a so-called environment which is populated with processes that each represent one rental of a FleetUnit from a store holding those FleetUnits.
The request time for each rental is sampled from a dual normal distribution over time of day defined for each timeframe and use case in the use case definition csv file.
An example use case file is distributed with REVOL-E-TION for both Vehicles and mobile batteries (for explanation see chapter "Classes of Blocks") in the respective input directories.
Inside the code for the DES, a FleetDispatcher instance is created for each Fleet in the scenario, holding one store of FleetUnits per SubFleet, as well as a DispatchProcess instance for each request.

Each process not only covers the actual rental time (which itself is made up of an active part and idle time, both of which are sampled stochastically), but also a charging time to give the energy system enough time to recharge the FleetUnit.
This charging time follows from the energy the upcoming rental requires and from the FleetUnit's charging power, and it is placed before the rental: a FleetUnit can only be taken from its store once it has been back at base for at least that long.
The same holds for range extension FleetUnits with their own energy share, so a rental only starts once both the primary and the range extension FleetUnits have been resting long enough.
Since the charging time is derived from the request rather than from the FleetUnit's state, a FleetUnit without a traction battery of its own, which relies entirely on range extension, is available again immediately upon its return.
Note that the dispatch KPI "rate_blocked" attributes the charging time to the rental that caused it and therefore counts it after the return rather than before the departure.

Since vehicle SubFleets can be linked to mobile battery SubFleets through the scenario parameter "rex" for range extension, a process of a vehicle Fleet can require FleetUnits from its own store and from the linked battery Fleet's store at the same time.
Such a process then has a primary and a range extension FleetUnit, both of which need to be available for the process to be successful.
Once the environment has been run, every successful process that took range extension FleetUnits along is copied into the linked battery Fleet's dispatcher with the two roles swapped, so that the batteries also appear as rented within their own Fleet.
These copies are flagged as range extension, which is what distinguishes an internal service to another SubFleet of the same operator from an external rental in the economic evaluation.

Once all stores have been populated with FleetUnits and all processes have been created, the environment is run and determines which processes are successful (i.e. get their required FleetUnits) and which ones fail.

Dispatch events and the time based log

The result of the DES is an event table, implemented in the events.py file: essentially the demand list after dispatch, with one row per rented FleetUnit and process holding the requested time, the actual departure and return, the FleetUnit taken, the consumed energy, the driven distance and the Delta SOC.
Requests that could not be served are kept as rows without a FleetUnit and without dispatched values, which makes the table a complete record of the dispatch and allows the dispatch KPIs (success, utilization and blocked rate) to be derived from it.
Values are stored per event rather than per timestep, so the table is independent of the simulation timestep, and departure and return are resolved exactly.
A row is additionally flagged if the rental serves another SubFleet as a range extender rather than an external customer, which is what keeps the operator from invoicing themselves (see "crev_spec_time" in the parameter tables above).

The energy system model works per timestep, so each FleetUnit materializes its own time based log from its events.
This contains columns of availability in the energy system (called "atbase"), energy consumption while not at base, availability of external AC and DC charging, the Delta SOC ("dsoc") of a rental, the trip distance and the range extension flag ("rex").
Event values are distributed evenly over the rental period, as the DES resolves no intra-rental detail.
The distance is needed for vehicle SubFleets because even with a constant consumption it is no more traceable from the energy consumption due to the possibility of range extension.
Only if the dispatch of the FleetUnits is left to the optimizer (as opposed to the a priori power scheduling) myopically (i.e. in the "rh" strategy"), the 'dsoc' column is actually transferred to a hard minimum SOC constraint for the optimizer, as all other cases handle this intrinsically.

A Fleet reading a time based log from file ("log" data source) keeps that log as it is and reconstructs its events from the occupancy it records.
This reconstruction is necessarily incomplete: a log holds no record of requests that were never served, none of the recharging after a return, and no range extension flag, so such a Fleet reports no dispatch KPIs and all of its rentals are treated as external.
Two rentals following each other without an idle timestep in between are indistinguishable in a log and are recovered as a single event.
Replaying an event file ("events" data source) has none of these limitations and reproduces the dispatch of the run it was written by exactly, which is the way to obtain deterministic results despite the stochastic sampling of the DES.

A Priori Power Scheduling

Dependent on the chosen scheduling method ("mode_scheduling") of a SubFleet a charging schedule for the SubFleet's FleetUnits is calculated before the linear optimization starts (a priori).
This approach is applied to FleetUnits in SubFleets with optimization level of all types of uncoordinated charging ('uc') and rule-based strategies ('equal', 'fcfs', 'soc').
All optimization levels causing an a priori calculation of the FleetUnit's charging power require a unidirectional ('ud') integration level ("lvl_cap").
In addition to the optimization level, rule-based systems may implement a static load management system by defining the maximum available power using the "power_lim_static" parameter.
If "power_lim_static" is set to 'None', static load management is disabled, and the system defaults to dynamic load management.
For all FleetUnits within uncoordinated or rule-based SubFleets in addition to the charging power when being plugged in at the local energy system the required charging power on-route at external charging infrastructure is calculated.
The precomputed charging schedules are then enforced in the linear optimization model by applying them as fixed power constraints to the relevant model flows.

General Approach of A Priori Power Scheduling

The a priori power scheduling process is iterative and operates on a per-timestep basis as the State of Charge (SOC) at each timestep is influenced by the previous timestep.
Within a single timestep in a first step the charging powers for all FleetUnits plugged in to the local energy system (column 'atbase' in log file is set to True) are calculated.
Initially, the charging power calculation for uncoordinated FleetUnits connected to the local energy system is determined, followed by rule-based FleetUnits with static load management.
In the next step the remaining available power within the local energy system is allocated to all FleetUnits being part of the dynamic load management.
The linear optimization algorithm subsequently handles the allocation of any excess power.
Lastly, the external AC and DC charging power is calculated for FleetUnits for which this infrastructure is currently available (indicated by the 'atac' or 'atdc' columns being True in the log file).

Load management system

For rule-based FleetUnit instances within a Fleet instance, a static power limit can be defined in the scenario file, which restricts the cumulative charging power of all FleetUnits within the Fleet.
If no static power limit is set, the Fleet's FleetUnits will be part of a dynamic load management.
In this case, the available power within the local energy system is distributed among all FleetUnits that are part of the dynamic load management.
The available power is calculated by subtracting the required power of FixedDemand blocks and the power already allocated to all uncoordinated FleetUnits and rule-based FleetUnits in Fleets with static load management from the maximum available power.
The maximum available power within the local grid is calculated by summing up the output powers of GridConnection, PVSource, WindSource, and ControllableSource blocks.
All Fleets without a static power limit that include rule-based FleetUnits have to be of the same integration level as they are all controlled by the same dynamic load management system; the rule-based charging strategy is applied as described.
Furthermore, if this integration level is supposed to be 'equal', all SubFleets have to be connected to the same bus via their corresponding Fleet.
As a dynamic load management system requires knowledge about the available power within the local energy system for each timestep, it is not possible to combine a dynamic load management system with a StationaryBattery block.
This would require an a priori calculation of the StationaryBattery's SOC which is not possible in a straight-forward way, due to different prioritization of power sources based on their current opex and the efficiency of the SystemCore.

Charge Scheduling Modes ("mode_scheduling")

• uncoordinated charging: only a single FleetUnit neglecting effects caused by other FleetUnits and the local energy system's limitations is taken into account to determine its charging power.
  • 'uc':Once plugged in to the local energy system, the FleetUnit charges at the maximum charging power specified for the FleetUnit in the scenario file until the target SOC is reached.
    Charging power is determined for a single FleetUnit in isolation, neither considering the influence of other FleetUnits nor any type of load management system.
• rule-based charging strategies: multiple FleetUnits (within the same Fleet for static load management or across several Fleets for dynamic load management) are considered to determine their charging power.
  • 'equal': Charging power is evenly distributed among all FleetUnits within the Fleet. Any surplus power, resulting from a FleetUnit reaching its target SOC, is redistributed among the remaining FleetUnits until all available power is allocated.
  • 'fcfs': FleetUnits are prioritized by their plug-in time, with the earliest plug-in receiving the highest priority. In cases where plug-in times are identical, FleetUnits are prioritized alphabetically by name.
  • 'soc': FleetUnits are prioritized based on their SOC, with the lowest SOC receiving the highest priority. For identical SOC levels, priorities are assigned alphabetically by the FleetUnits' names.
• optimized charging: The charging power of the FleetUnits is optimized by the linear optimization algorithm without any a priori calculation.

External charging

The power for all FleetUnits with available external charging infrastructure (column 'atac' or 'atdc' in log file is set to True) is calculated.

• AC charging: Once AC charging gets available, the required energy until the return to the local energy system is calculated.
  If the current SOC does not ensure a return SOC above the specified minimum return SOC (does not consider self-discharge), AC charging is activated. The specified charging power is then applied until the target SOC is reached.
• DC charging: If DC charging is available and the SOC at the next timestep with a charging possibility is below 5 %, DC charging is activated for the current timestep. The maximum SOC for DC charging is 80 % neglecting "soc_target".

A Posteriori Aging Model (also available for StationaryBattery)

Simple semi-empirical aging models are implemented for a blocks containing electric storages (ElectricFleetUnit and StationaryBattery).
More specifically, these are the Naumann model (publication 1 and publication 2) for LFP batteries and the Schmalstieg model for NMC batteries.
They are both contained within the battery.py file and work on superposing calendric and cycle aging.
The latter is based on cycling parameters (e.g. depths of discharge) determined using a rainflow algorithm for each horizon.

Results of the aging model (if activated through the scenario file parameter "aging") are evaluated and the capacity degradation applied as a restricted usable SOC window after every horizon.
This results in a dependency of the aging model output on the horizon resolution (i.e. length) with the extreme case of the "go" strategy, where only the State of Health at the end of the simulation timeframe is evaluated.
Please note that the lifetime used for economic extrapolation of simulation results is not connected to the aging model and sizing the battery block on its results is infeasible due to it being run a posteriori and nonlinearly.
Therefore, the aging model's output does not have any influence on the economic results of the simulation, but is only of an informative character.

Outputs

REVOL-E-TION creates a uniquely named (containing the runtimestamp and the scenario file name) result directory for every run.
There, the following files are saved (some of them optionally):

• The log file of the run named <runtimestamp>_<scenario_file_name>_log.csv. This contains all terminal log messages of the run, including errors and warnings.
• A single result summary file named <runtimestamp>_<scenario_file_name>_summary.csv containing all noncomplex (int, float, bool or string) attributes of the SimulationRun, Scenario, and all blocks in the scenario.
• A single result summary file named <runtimestamp>_<scenario_file_name>_summary.pkl. This is the same as the summary csv file but in pickle format which eases further processing.
• A single scenario status file named <runtimestamp>_<scenario_file_name>_status.csv containing the current status ('started', 'fully initialized', 'completed horizon x out of y', 'successful', 'failed') and occurring exception tracebacks of all scenarios in the run. It is constantly updated during the run and can be used for monitoring purposes and filtering in the analysis of the results.
• (Optional) One result timeseries file per scenario named <runtimestamp>_<scenario_file_name>_<scenario_name>_results_ts.feather. This contains all timeseries results of the energy system for every timestep, facilitating easy plotting.
• (Optional) One sampled demand file per Fleet whose usage is generated from use cases, named <runtimestamp>_<scenario_file_name>_<scenario_name>_<fleet_name>_demand.feather. This holds the requests the DES was run on and can be fed back in through the 'demand' data source to skip the sampling stage. Input files are accepted in both csv and feather format.
• (Optional) One time based log file per dispatched Fleet named <runtimestamp>_<scenario_file_name>_<scenario_name>_<fleet_name>_log.feather. This is what the energy system model is run on and can be fed back in through the 'log' data source.
• (Optional) One event file per dispatched Fleet named <runtimestamp>_<scenario_file_name>_<scenario_name>_<fleet_name>_events.feather. This is the dispatch result the log is derived from and can be fed back in through the 'events' data source to replay the run exactly. It supersedes the log as a reuse format, as it additionally holds the requests that could not be served, the range extension flag and the exact departure and return times. Fleets whose usage is read from file are not dispatched and therefore write no event file.
• (Optional) One plot file per scenario named <runtimestamp>_<scenario_file_name>_<scenario_name>.html containing an interactive line plot of the dispatch and state variables (i.e. SOCs and SOHs) of every block in the scenario.