https://github.com/tumftm/revol-e-tion
Site level energy system optimization model toolbox for investigations of EV fleet integration and management strategies
https://github.com/tumftm/revol-e-tion
bidirectional-charging energy-system-model ev-integration microgrid minigrid smart-charging v2b v2g v2h v2s
Last synced: over 1 year ago
JSON representation
Site level energy system optimization model toolbox for investigations of EV fleet integration and management strategies
- Host: GitHub
- URL: https://github.com/tumftm/revol-e-tion
- Owner: TUMFTM
- License: apache-2.0
- Created: 2024-05-14T15:33:38.000Z (about 2 years ago)
- Default Branch: main
- Last Pushed: 2025-03-31T06:37:57.000Z (over 1 year ago)
- Last Synced: 2025-04-07T21:39:51.510Z (over 1 year ago)
- Topics: bidirectional-charging, energy-system-model, ev-integration, microgrid, minigrid, smart-charging, v2b, v2g, v2h, v2s
- Language: Python
- Homepage:
- Size: 25 MB
- Stars: 10
- Watchers: 2
- Forks: 3
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# 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](https://oemof.org) 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
## 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", Under Review, Available at SSRN, https://dx.doi.org/10.2139/ssrn.5127283
## 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 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) are modeled individually within a block called a CommoditySystem.
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 a Battery CommoditySystem as well as multiple use cases in different time frames (e.g. summer/winter) for the commoditites.
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 10, 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 at the institute's [GitHub](https://github.com/TUMFTM/REVOL-E-TION) and can be cloned from there using
```
git clone https://github.com/TUMFTM/REVOL-E-TION.git
```
#### Step 2: Create a clean virtual environment
It is recommended to create and activate a clean virtual environment for the installation of REVOL-E-TION.
This can be done using the following command:
```
python -m venv
source /bin/activate
```
or alternatively with conda:
```
conda create -n python=3.11
conda activate
```
#### Step 3: Install package and dependencies locally
Navigate to the root directory of the cloned repository and install the package and its dependencies using pip:
```
pip install -e .
```
This will install the ```revoletion``` package in editable mode, meaning that changes to the source code will be reflected in the installed package without reinstalling it.
#### Step 4: MILP Solver
REVOL-E-TION requires a [pyomo compatible](https://pyomo.readthedocs.io/en/stable/solving_pyomo_models.html#supported-solvers) Mixed Integer Linear Programming (MILP) solver (as does oemof).
The open-source [cbc](https://github.com/coin-or/Cbc/releases/latest) solver works well.
The proprietary [Gurobi](https://www.gurobi.com/downloads/) solver is recommended however, as it is faster in execution, especially for large problems and offers a free academic license.
If [Gurobi](https://www.gurobi.com/downloads/) is used, the version of Gurobi, gurobipy and the license file have to match.
To ensure this get the version of both your gurobi license/installation (```grbgetkey --version```) and the installed gurobipy package (```pip show gurobipy```).
If their major version numbers do not match, install the correct version of gurobipy using pip:
```
pip install gurobipy==
```
#### Step 5: Basic Usage
REVOL-E-TION can be run using one of two terminal commands:
1. Call to the main module: ```python -m revoletion.main --settings --scenario ``` (best for local execution on host machine, e.g. through a run configuration in PyCharm)
2. Call to the entry point: ```revoletion --settings --scenario ``` (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 possible arguments are:
| Argument | Short argument | Long argument | Default value | Description | Valid input |
|---------------------------------|----------------|--------------------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Scenario file path | -scn | --scenario | - | Path to scenario file | string with filename of scenario file (options specified below) |
| Settings file path | -set | --settings | - | Path to settings file | string with filename of settings file (options specified below) |
| Rerun previous run | -rer | --rerun | False | Rerun scenarios of a previous run which were not completed successfully (due to unexpected termination of SimulationRun or non-deterministic infeasibilities) | False or string with (a) directory name within output directory from settings file containing results of previous run or (b) absolute path to that directory |
| Rerun only infeasible scenarios | -rin | --rerun_infeasible | True | Rerun infeasible scenarios, for which the solver did not find an optimal solution (may lead to the same result again) Neglected for ```--rerun False``` | True, False |
| Execute SimulationRun | -exe | --execute | True | Execute SimulationRun immediately (only for debugging purposes, not required for basic usage) | True, False |
For both the scenario and settings file path arguments, three options are available:
1. No argument is passed: graphical selection dialogs open automatically to select file.
2. Only filename passed: file is searched in (a) the current working directory and (b) in the REVOL-E-TION example directory.
3. Valid path passed: file is searched in the specified path (best for remote execution on a server)
Both the scenario and settings files are CSVs.
Their exact API is described in the sections "Settings Input Parameters" and "Scenario Input Parameters".
Runnable example scenario and settings files are 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 in the settings file.
Furthermore, to describe the mapping of different timeframes defining behavior of CommoditySystems (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 the settings file.
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 in the settings file depending on the hardware used.
#### Common Problems & Troubleshooting
| Error message | Cause | Solution |
|----------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Errors while installing the required Python packages | various | Make sure to start with a clean Python environment using Python >=3.11. We recommend conda for dependency resolution. |
| Gurobi related installation & execution errors | Faulty Gurobi installation, missing Gurobi license, or faulty Gurobipy version | Check your Gurobi installation by executing ```gurobi-cl``` in a shell. If the command itself fails, Gurobi itself is not installed properly. In this case, follow the [Gurobi Install and Troubleshooting Guide](https://support.gurobi.com/hc/en-us/articles/14799677517585-Getting-Started-with-Gurobi-Optimizer). If the command prints your Gurobi version and license information, make sure Gurobipy has the same version number as Gurobi itself. |
| ```IndexError: Block "X": Input timeseries data does not cover simulation timeframe``` | A timeseries data file provided does not cover the complete simulation period or resampling it has failed | Specify a different simulation period or select a different timeseries input file. Make sure the entire simulation timeframe (possibly including overhanging data for the last prediction horizons) |
| ```Class "X" not found in blocks.py file``` | The class name specified in the blocks dictionary in the scenario file is not specified in REVOL-E-TION | Check the blocks dictionary string in the scenario csv file for typos. |
| ```Scenario failed: Infeasible or Unbounded (To solve this error try to set investment limits for blocks or for the scenario)``` | Depending on the costs specified the optimization problem might be unbounded as infinite investment is beneficial | Redefine the provided cost structure (i.e. reduce prices for energy feed-in or increase CAPEX or OPEX for energy generation) |
| Any other error messages or errors | various | REVOL-E-TION prints specific error messages in most cases which help you to understand the cause of the error. Nevertheless, REVOL-E-TION is still in development and therefore might contain bugs and errors that are not covered yet. If you encounter a bug or an error message that you do not understand, please feel free to open an issue on GitHub or contact the developers. |
## General Terms & Definitions
The following table details common terms occuring 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) and settings file each. 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 some timeseries inputs. |
| Strategy | The (energy management) strategy to dispatch the energy system's blocks generally (see CommoditySystem capability levels later on for differences). 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 feasibilty 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. |
## Classes of Blocks
The following table details the classes of blocks that can be specified in the "blocks" parameter of the scenario in the scenario file with respective names for the instances. Block instances cannot be named "scenario". Each instance requires a certain set of parameters dependent on its class. These are specified in the following chapter.
| Class Name | Description |
|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| InvestBlock | Parent class for all blocks that are possibly being sized in optimization (i.e. where an investment decision has to be taken) and for which entering ```'opt'``` as the size in the scenario file will trigger that size optimization. However, this option is only compatible with the "go" strategy. Class contains mostly methods for result evaluation. |
| RenewableInvestBlock | Parent class for all InvestBlocks representing a renewable source with a curtailment sink component and variable potential power (defined as a fraction of nominal power to enable sizing) over time. Child of class InvestBlock. |
| SystemCore | Class for collection of central energy system components (AC and DC buses and the two unidirectional transformers between them). Child of class Block. 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. |
| FixedDemand | Class for undeferrable (i.e. inflexible) power demand such as households. Child of class Block. Power timeseries is defined in a csv file. |
| PVSource | Class for photovoltaic array. Child of class RenewableInvestBlock. Power potential is defined either in a [Solcast](https://solcast.com/) or [PVGIS](https://re.jrc.ec.europa.eu/pvg_tools/en/) formatted csv file (both pre-downloaded) or retrieved from either the [Solcast](https://docs.solcast.com.au/#intro) or [PVGIS](https://joint-research-centre.ec.europa.eu/photovoltaic-geographical-information-system-pvgis/getting-started-pvgis/api-non-interactive-service_en) API (selection of API requires active internet connection. In addition the Solcast API requires an active subscription plan. There is a limited free plan for researchers). |
| WindSource | Class for wind turbine. Child of class RenewableInvestBlock. Power potential is defined either in a csv timeseries file or 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. |
| ControllableSource | Class for independently controllable power sources (e.g. fossil generator, hydro power plant) that is unlimited in energy. Child of class InvestBlock. |
| GridConnection | Class for utility grid and/or energy market connection. Child of class InvestBlock. A GridConnection instance can contain multiple GridMarkets. Definition of GridMarket instances happens in a separate csv file. |
| StationaryEnergyStorage | Class for stationary battery energy storage systems. Child of class InvestBlock. 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. |
| CommoditySystem | Parent class for fleets of mobile battery based devices (e.g. electric vehicles or battery rental). Child of class InvestBlock. Behavior is defined in a csv file (the log) that can either be given or generated within the integrated Discrete Event Simulation from stochastic behavioral parameters to be given in a usecase definition csv file for different timeframes defined in ```mapper_timeframe.py``` in code. Each CommoditySystem consists of at least one MobileCommodity representing one vehicle or battery. |
| VehicleCommoditySystem | Class for fleet of electric vehicles, possibly with range extension using a BatteryCommoditySystem (see [publication](https://ieeexplore.ieee.org/document/9905305)). Child of class CommoditySystem. |
| BatteryCommoditySystem | Class for fleet of mobile batteries. Child of class CommoditySystem. |
| ICEVSystem | Class for comparative calculation of ICEV fleet cost.
## Settings Input Parameters
The settings file defines all common parameters for the scenarios in a simulation run.
Its structure is much simpler than with the scenario file.
The following table specifies each parameter of a complete settings file, all of which are required for every run.
| Parameter | Type | Description | Valid values or format |
|-------------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|
| solver | str | Name of the solver to be used by pyomo for linear optimization | Tested: ['cbc', 'gurobi', 'gplk'] |
| parallel | bool | Trigger whether to use parallelization through python's multiprocessing library or work through the scenarios sequentially on a single core. If "paralllel" is True with only one scenario, sequential mode is selected automatically and a corresponding warning is logged. The benefit of parallelization of scenarios is naturally greatest in runs with many scenarios defined. | ['True', 'False'] |
| max_process_num | int,str | Maximum number of processes to be used in case "parallel" is True. This should not exceed the number of threads of the processor(s) used to ensure computational efficiency. Especially in the "go" strategy, REVOL-E-TION is RAM heavy, therefore an even lower setting might make sense in runs with many "go" scenarios. Parameter is ignored if "parallel" is False. | 'max', [0,inf[ |
| path_input_data | str | Directory to search for input data. If path is specified as 'example' the example project from the package directory will be executed, if specified as 'scenario_file_dir' input data will be search in the directory of the scenario file. Otherwise the path specified for this parameter will be used. | 'example', 'scenario_file_dir' or any path |
| path_output_data | str | Directory to save output data. If path is specified as 'package' the default directory within the package directory is used. Otherwise the path specified for this parameter will be used. | 'package' or any path |
| save_results_timeseries | bool | Trigger whether to save the result timeseries (separately for every scenario) into the selected or default result directory. | ['True', 'False'] |
| save_results_dispatch | bool | Trigger whether to save the DES results (i.e. the resulting log and process dataframe) as separate csv files per CommoditySystem and scenario into the selected or default result directory for later usage in other simulations. | ['True', 'False'] |
| print_results | bool | Trigger whether to print core result values of a scenario (e.g. the LCOE) and each block (e.g. the optimum size) to the terminal after the scenario has successfully completed. | ['True', 'False'] |
| save_plots | bool | Trigger whether to save the dispatch plot of each scenario (containing roughly the same information as the timeseries results in visual form) as a separate html file into the selected or default result directory. Since the resulting files are easily in the megabyte range, setting this option to True results in considerable storage requirements. This option is independent of the show_plots option. | ['True', 'False'] |
| show_plots | bool | Trigger whether to open each scenario's dispatch plot immediately upon generation using the default web browser. This option is independent of the save_plots option. | ['True', 'False'] |
| save_system_graphs | bool | Trigger whether to save a separate pdf file of a graph representation of every scenario's energy system in the selected or default result directory. Mainly useful for debugging purposes of block definitions. | ['True', 'False'] |
| dump_model | bool | Trigger whether to save a .lp file containing the mathematical optimization model for later solving through pyomo. | ['True', 'False'] |
| debugmode | bool | Trigger whether to log and print solver progress information during the solving process. This is resource intensive and should therefore be avoided unless explicitly necessary. | ['True', 'False'] |
## Scenario Input Parameters
The scenario file defines all noncomplex (i.e. integer, float, string, boolean) parameters of the scenarios.
Complex (multidimensional) parameters are mostly defined through links to other files (by filename) in the scenario file.
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 are these parameters required and read in.
Therefore not every scenario file contains all possible parameters.
Multiple scenarios can be defined as multiple columns.
The first row (header) of each scenario column defines the scenarios name.
By adding a '#' to the start of the name of a scenario column, the scenario is ignored during the simulation process.
The first column of the scenario file defines the name of the block the parameter in the second column applies to.
An example scenario file is provided in the ```./example``` directory.
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.
| Block | Key | Name | Type | Description | Valid values or format |
|-------------------------|-----------------------|------------------------------------------------------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| Scenario | starttime | Start time | str | Start time of the project and the simulation in local time. If no time is given in addition to the date the project starts at 00:00 local time | 'dd.mm.YYYY HH:MM' |
| | timestep | Time step | str | Time step used for the simulation | formats compatible with pd.to_timedelta() such as '15min' or '1H' |
| | sim_duration | Simulation duration | int or str | Simulation duration. If given as integer the number is interpreted as number of days. Specifying a pandas.Timedelta() compliant string is also supported. The duration is rounded down to the specified timestep. | [1, inf[ or str such as '1 day 12 hours 14 minutes' |
| | prj_duration | Project duration | int | Project duration in years to which the economic results of the simulation duration are extrapolated | [1, inf[ |
| | compensate_sim_prj | Specific Capex/Opex compensation trigger | bool | Trigger whether to optimize for sim duration (False) or project duration (True) | e.g. 'EUR', 'USD' |
| | strategy | Strategy | str | Optimization strategy | 'go' or 'rh' (global optimum, rolling horizon) |
| | len_ph | Prediction horizon length | int | Length of the prediction horizon in hours. Neglected for every optimization strategy other than 'rh' | [1, inf[ |
| | len_ch | Control horizon length | int | Length of the control horizon in hours. Neglected for every optimization strategy other than 'rh' | [1, inf[ |
| | truncate_ph | Truncate Prediction Horizon | bool | Toggles whether to truncate predictions horizons to simulation end time when using 'rh' optimization strategy. If activated all horizons are truncated to the simulation end time. Deactivation requires additional input data for all Prediction Horizons even beyond the end of the simulation specified by "starttime" and "sim_duration" | True, False |
| | invest_max | Maximum initial investment costs | float | Limit the initial investment costs to a specific amount. If no limit should be considered set this parameter to None | [0, inf[ or None |
| | wacc | Weighted average cost of capital | float | Weighted average cost of capital: discount rate for future expenses/revenues and energies per year | [0, 1] |
| | currency | Currency | str | Currency used to display results of economic calculations. No influence of calculation itself, only used for displaying. | e.g. 'EUR', 'USD' |
| | latitude | Latitude | float | Latitude of the location of the local energy system. Used to determine timezone, pv and wind data. Has to be given in WGS84 | [-90, 90] |
| | longitude | Longitude | float | Latitude of the location of the local energy system. Used to determine timezone, pv and wind data. Has to be given in WGS84 | [-90, 90] |
| | cost_eps | Epsilon costs | float | Cost added to some flows in order to disincentivice circular flows | [0, inf[ |
| | filename_mapper | Filename TimeframeMapper | str | Filename of the file containing the mapping function for the CommoditySystems' DES. The file has to The filename has to be given without the ending ".py". The file itself has to be placed in the project directory. | string with filename of python file without ".py" |
| | blocks | Blocks | dict | All blocks present in the scenario except for the SystemCore, which is added automatically, in the format {block_name: class_name}. Non valid names are 'run', 'scenario' and 'core' (default name for block of class SystemCore). | '{'custom block name': 'class name of block'}' |
| SystemCore | size_acdc_existing | Existing AC/DC size | float or str | Installed power of the AC/DC converter in the SystemCore in W. To set both converter sizes to the same value set one size to 'equal' | [0, inf[ or 'equal' |
| | capex_existing_acdc | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_acdc_max | Maximum size of AC/DC converter | float | Maximum size of the AC/DC converter of the SystemCore including existing size. To enable unlimited investment set this parameter to None. To set both converters' maximum investments to the same value set one maximum investment to 'equal' | [0, inf[ or None |
| | invest_acdc | Investment into AC/DC converter | bool or str | Enable additional investment into the AC/DC converter of the SystemCore. If one of the invest parameters is set to 'equal' both investments are forced to the same size | True, False, 'equal' |
| | size_dcac_existing | Existing DC/AC size | float or str | Installed power of the DC/AC converter in the SystemCore in W. To set both converter sizes to the same value set one size to 'equal' | [0, inf[ or 'equal' |
| | capex_existing_dcac | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_dcac_max | Maximum size of DC/AC converter | float | Maximum size of the DC/AC converter of the SystemCore including existing size. To enable unlimited investment set this parameter to None. To set both converters' maximum investments to the same value set one maximum investment to 'equal' | [0, inf[ or None |
| | invest_dcac | Investment into DC/AC converter | bool or str | Enable additional investment into the DC/AC converter of the SystemCore. If one of the invest parameters is set to 'equal' both investments are forced to the same size | True, False, 'equal' |
| | capex_spec | Specific capital expenditures | float | Specific capital expenditures for each of the converters in the SystemCore: cost in currency per installed power (cumulative size of "size_acdc" and "size_dcac") in W | [0, inf[ |
| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures for each of the converters in the SystemCore: cost in currency per year per installed power in W | [0, inf[ |
| | opex_spec | Specific operational expenditures | float or str | Specific operational expenditures for each of the converters in the SystemCore cost in currency per converted energy in Wh. Energy is measured at converter inflow | string with filename or [0, inf[ |
| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |
| | ccr | Cost change ratio | float | Cost change ratio of the block's nominal price per year to be considered for replacement after its lifespan | [0, inf[ |
| | eff_dcac | DC/AC efficiency | float | Efficiency of the DC/AC converter in the SystemCore | [0, 1] |
| | eff_acdc | AC/DC efficiency | float | Efficiency of the AC/DC converter in the SystemCore | [0, 1] |
| FixedDemand | load_profile | Load Profile | str | Load profile for the fixed demand. Can be given as filename of a csv file containing a timeseries specifying the fixed demand of the block or as string defining a constant load or one of the standard load profiles by BDEW. If a filename is given, the file has to include the two columns 'time' and 'power' including a timezone aware timestamp and the corresponding power value in W | string with filename, {'const', 'H0', 'G0', 'G1', 'G2', 'G3', 'G4', 'G5', 'G6', 'L0', 'L1', 'L2'} |
| | consumption_yrl | Yearly consumption | float | Yearly consumption in Wh. Only taken into account if a standard load profile or 'const' is defined in "load_profile" | [0, inf[ |
| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |
| | crev_spec | Specific customer revenue | float | Specific customer revenue for consumed energy in currency per Wh | [0, inf[ |
| WindSource | size_existing | Existing size | float | Installed rated power of wind turbine in W | [0, inf[ |
| | capex_existing | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_max | Maximum size | float | Maximum size of WindSource including existing size. To enable unlimited investment set this parameter to None | [0, inf[ or None |
| | invest | Investment | bool | Enable additional investment into the wind turbine | True, False |
| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |
| | data_source | Data source | str | Data source for wind power. Wind power can either be calculated from the PV data or given as a separate file | string containing the name of a block of class PVSource or 'file' |
| | height | Height | float | Hub height of the wind turbine in meters | [0, inf[ |
| | filename | Filename | str | Filename of csv file containing wind power data with the columns time (timezone aware timestamp) and power_spec (specific power in W per rated power in W) for each defined timestamp | string with filename |
| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed rated power in W | [0, inf[ |
| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed rated power in W | [0, inf[ |
| | opex_spec | Specific operational expenditures | float or str | Specific operational expenditures: cost in currency per generated energy in Wh. Can be given as float or filename of a csv file containing a timeseries | string with filename or [0, inf[ |
| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |
| | ccr | Cost change ratio | float | Cost change ratio of the block's nominal price per year to be considered for replacement after its lifespan | [0, inf[ |
| | eff | Efficiency | float | Efficiency of the wind turbine | [0, 1] |
| PVSource | size_existing | Existing size | float | Installed peak power of the pv array in in Wp | [0, inf[ |
| | capex_existing | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_max | Maximum size | float | Maximum size of PVSource including existing size. To enable unlimited investment set this parameter to None | [0, inf[ or None |
| | invest | Investment | bool | Enable additional investment into the PV system | True, False |
| | data_source | Data source | str | Data source for pv power. This can be PVGIS or Solcast API or a file containing data from PVGIS or Solcast. If Solcast API is chosen a valid API key has to specified in in the settings file. | 'pvgis api', 'solcast api', pvgis file', 'solcast file' |
| | filename | Filename | str | Name of a PVGIS or Solcast csv file if "data_source" is set to 'pvgis file' or 'solcast file'. Name of a parameter file or None to use the default values if 'pvgis api' or 'solcast api' is chosen. | string with filename |
| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |
| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed peak power in W | [0, inf[ |
| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed peak power in W | [0, inf[ |
| | opex_spec | Specific operational expenditures | float or str | Specific operational expenditures: cost in currency per generated energy in Wh. Can be given as float or filename of a csv file containing a timeseries | string with filename or [0, inf[ |
| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |
| | ccr | Cost change ratio | float | Cost change ratio of the block's nominal price per year to be considered for replacement after its lifespan | [0, inf[ |
| | eff | Efficiency | float | Efficiency of the PV array, taking into account all losses occurring from insulation up to the point of feeding power into the bus to which the block is connected | [0, 1] |
| ControllableSource | size_existing | Existing size | float | Installed rated power of the source in W | [0, inf[ |
| | capex_existing | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_max | Maximum size | float | Maximum size of ControllableSource including existing size. To enable unlimited investment set this parameter to None | [0, inf[ or None |
| | invest | Investment | bool | Enable additional investment into the power source | True, False |
| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |
| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed power in W | [0, inf[ |
| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed peak power in W | [0, inf[ |
| | opex_spec | Specific operational expenditures | float or str | Specific operational expenditures: cost in currency per generated energy in Wh. Can be given as float or filename of a csv file containing a timeseries | string with filename or [0, inf[ |
| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |
| | ccr | Cost change ratio | float | Cost change ratio of the block's nominal price per year to be considered for replacement after its lifespan | [0, inf[ |
| | eff | Efficiency | float | Efficiency of the source | [0, 1] |
| GridConnection | size_g2s_existing | Existing maximum power from grid to local site | float | Installed power for the power flow from the grid to the local site in W. To set both directions' existing powers to the same value set one size to 'equal' | [0, inf[, 'equal' |
| | capex_existing_g2s | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_g2s_max | Maximum size of Grid2Site | float | Maximum size of Grid2Site including existing size. To enable unlimited investment set this parameter to None. To set both directions' maximum investments to the same value set one maximum investment to 'equal' | [0, inf[ or None |
| | invest_g2s | Investment into Grid2Site | bool or str | Enable additional investment into the maximum power from the grid to the local site. To ensure the same additional power for both directions set one invest variable to 'equal' | [0, inf[ |
| | size_s2g_existing | Existing maximum power from local site to grid | float | Installed power for the power flow from the local site to the grid in W. To set both directions' existing powers to the same value set one size to 'equal' | [0, inf[, 'equal' |
| | capex_existing_s2g | Consider existing block size in capex | bool | Trigger whether to consider existing component size in initial capex calculation. Replacement capex are unaffected. | True, False |
| | size_s2g_max | Maximum size of Site2Grid | float | Maximum size of Site2Grid including existing size. To enable unlimited investment set this parameter to None. To set both directions' maximum investments to the same value set one maximum investment to 'equal' | [0, inf[ or None |
| | invest_s2g | Investment into Site2Grid | bool or str | Enable additional investment into the maximum power from the local site to the grid. To ensure the same additional power for both directions set one invest variable to 'equal' | [0, inf[ |
| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |
| | peakshaving | Peakshaving | str | Peakshaving period. Peakshaving can be deactivated by setting this parameter to 'None' | 'None', 'day', 'week', 'month', 'quarter', 'year' |
| | opex_spec_peak | Operational expenditures for peakshaving | float | Specific operational expenditures for maximum power drawn from the public grid in cost in currency per peak power in W per peakshaving duration | [0, inf[ |
| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed power (cumulative size of "size_s2g" and "size_g2s") in W of the grid connection | [0, inf[ |
| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed power (cumulative size of "size_s2g" and "size_g2s") in W of the grid connection | [0, inf[ |
| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |
| | ccr | Cost change ratio | float | Cost change ratio of the block's nominal price per year to be considered for replacement after its lifespan | [0, inf[ |
| | eff | Efficiency | float | Efficiency of the grid connection