{"id":22745913,"url":"https://github.com/tumftm/revol-e-tion","last_synced_at":"2025-04-14T10:07:33.875Z","repository":{"id":262966716,"uuid":"800572217","full_name":"TUMFTM/REVOL-E-TION","owner":"TUMFTM","description":"Site level energy system optimization model toolbox for investigations of EV fleet integration and management strategies","archived":false,"fork":false,"pushed_at":"2025-03-31T06:37:57.000Z","size":26265,"stargazers_count":10,"open_issues_count":0,"forks_count":3,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-04-07T21:39:51.510Z","etag":null,"topics":["bidirectional-charging","energy-system-model","ev-integration","microgrid","minigrid","smart-charging","v2b","v2g","v2h","v2s"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/TUMFTM.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-05-14T15:33:38.000Z","updated_at":"2025-03-31T13:19:01.000Z","dependencies_parsed_at":"2024-12-14T13:01:28.369Z","dependency_job_id":"91f8e47c-3f84-428e-a24f-5e7b119fb20e","html_url":"https://github.com/TUMFTM/REVOL-E-TION","commit_stats":{"total_commits":778,"total_committers":5,"mean_commits":155.6,"dds":0.4768637532133676,"last_synced_commit":"5f50bfbe597853e1ba47651aa7c389c0ae1d7d83"},"previous_names":["tumftm/revol-e-tion"],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TUMFTM%2FREVOL-E-TION","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TUMFTM%2FREVOL-E-TION/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TUMFTM%2FREVOL-E-TION/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TUMFTM%2FREVOL-E-TION/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/TUMFTM","download_url":"https://codeload.github.com/TUMFTM/REVOL-E-TION/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248647225,"owners_count":21139084,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bidirectional-charging","energy-system-model","ev-integration","microgrid","minigrid","smart-charging","v2b","v2g","v2h","v2s"],"created_at":"2024-12-11T02:09:18.622Z","updated_at":"2025-04-14T10:07:33.855Z","avatar_url":"https://github.com/TUMFTM.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# REVOL-E-TION ![System diagram](./images/revol-e-tion_icon.svg)\n\n### Resilient Electric Vehicle Optimization model for Local Energy TransitION\n\nREVOL-E-TION is an energy system model toolbox designed to optimize integration of electric vehicle fleets into \nlocal energy systems such as mini- and microgrids, company sites, apartment blocks or single homes and estimate\nthe resulting technoeconomic potentials in terms of costs and revenues within the energy (and optionally also the\nmobility system). It is built as a wrapper on top of the [oemof](https://oemof.org) energy system model framework. \n\n#### Created by \nPhilipp Rosner, M.Sc. and Brian Dietermann, M.Sc. \nInstitute of Automotive Technology \nDepartment of Mobility Systems Engineering \nTUM School of Engineering and Design \nTechnical University of Munich \nphilipp.rosner@tum.de \nSeptember 2nd, 2021\n\n#### Contributors\nMarcel Brödel, M.Sc. - Research Associate 01/2024-\n\nDavid Eickholt, B.Sc. - Semester Thesis submitted 07/2021 \nMarcel Brödel, B.Sc. - Semester Thesis submitted 05/2022 \nHannes Henglein, B.Sc. - Semester Thesis submitted 10/2022 \nMarc Alsina Planelles, B.Sc. - Master's Thesis submitted 10/2022 \nJuan Forero Yacaman - Bachelor's Thesis submitted 04/2023 \nElisabeth Spiegl - Bachelor's Thesis submitted 06/2023 \nAlejandro Hernando Armengol, B.Sc. - Master's Thesis submitted 10/2023 \nHannes Henglein, B.Sc. - Master's Thesis submitted 01/2024 \nFlorian Melzig, B.Sc. - Master's Thesis submitted 10/2024 \n\n## Licensing\nREVOL-E-TION is licensed under the Apache 2.0 open source license. \nThe full license text can be found in the LICENSE file in the root directory of the repository.\n\n## Related publications\n- 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.\n- 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\n- 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\n\n## Description \nREVOL-E-TION is a scalable generator for (mixed integer) linear energy system models of local energy systems with or without electric vehicle fleets.\nIt can be used to optimize component sizes and/or dispatch behavior of the system to achieve least cost in the simulation timeframe.\nSimulation results are later extrapolated and discounted to a project timeframe to estimate the technoeconomic potential of the system in the long run.\nPlease 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.\n\nREVOL-E-TION groups oemof components and buses into blocks representing real-world systems (e.g. a PV array) for easy application.\nElectric vehicles (in fact any mobile storage devices) are modeled individually within a block called a CommoditySystem.\nTheir 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.\nLog 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.\n\nThe following system diagram shows the basic structure including one example of each block class (blocks are indicated by dashed lines):\n![System diagram](./images/system_diagram.png)\n\n## Installation\nREVOL-E-TION is designed to run under Windows 10, Ubuntu 22.04 LTS and MacOS 15 Sequoia.\nWhile portability is generally built in, other operating systems are untested.\n\n#### Step 1: Getting the source code\nREVOL-E-TION is available at the institute's [GitHub](https://github.com/TUMFTM/REVOL-E-TION) and can be cloned from there using \n```\ngit clone https://github.com/TUMFTM/REVOL-E-TION.git\n```\n\n#### Step 2: Create a clean virtual environment\nIt is recommended to create and activate a clean virtual environment for the installation of REVOL-E-TION.\nThis can be done using the following command:\n```\npython -m venv \u003cpath_to_virtual_environment\u003e\nsource \u003cpath_to_virtual_environment\u003e/bin/activate\n```\nor alternatively with conda:\n```\nconda create -n \u003cname_of_virtual_environment\u003e python=3.11\nconda activate \u003cname_of_virtual_environment\u003e\n```\n\n#### Step 3: Install package and dependencies locally\nNavigate to the root directory of the cloned repository and install the package and its dependencies using pip:\n```\npip install -e .\n```\nThis 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.\n\n#### Step 4: MILP Solver\nREVOL-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).\nThe open-source [cbc](https://github.com/coin-or/Cbc/releases/latest) solver works well.\nThe 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.\nIf [Gurobi](https://www.gurobi.com/downloads/) is used, the version of Gurobi, gurobipy and the license file have to match.\nTo ensure this get the version of both your gurobi license/installation (```grbgetkey --version```) and the installed gurobipy package (```pip show gurobipy```).\nIf their major version numbers do not match, install the correct version of gurobipy using pip:\n```\npip install gurobipy==\u003cyour_gurobi_version\u003e\n```\n\n#### Step 5: Basic Usage\nREVOL-E-TION can be run using one of two terminal commands:\n1. Call to the main module: ```python -m revoletion.main --settings \u003csettings_file_path\u003e --scenario \u003cscenario_file_path\u003e ``` (best for local execution on host machine, e.g. through a run configuration in PyCharm)\n2. Call to the entry point: ```revoletion --settings \u003csettings_file_path\u003e --scenario \u003cscenario_file_path\u003e``` (best for remote execution on a server as it works irrespective of the current working directory as long as the correct environment is active)\n\nThe possible arguments are:\n\n| Argument | Short argument | Long argument | Default value | Description | Valid input |\n|---------------------------------|----------------|--------------------|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Scenario file path | -scn | --scenario | - | Path to scenario file | string with filename of scenario file (options specified below) |\n| Settings file path | -set | --settings | - | Path to settings file | string with filename of settings file (options specified below) |\n| 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 |\n| 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 |\n| Execute SimulationRun | -exe | --execute | True | Execute SimulationRun immediately (only for debugging purposes, not required for basic usage) | True, False |\n\nFor both the scenario and settings file path arguments, three options are available:\n\n1. No argument is passed: graphical selection dialogs open automatically to select file.\n2. Only filename passed: file is searched in (a) the current working directory and (b) in the REVOL-E-TION example directory.\n3. Valid path passed: file is searched in the specified path (best for remote execution on a server)\n\nBoth the scenario and settings files are CSVs.\nTheir exact API is described in the sections \"Settings Input Parameters\" and \"Scenario Input Parameters\".\nRunnable example scenario and settings files are provided in the example directory. \nSome parameters in the scenario file reference to other files specified by file name, mostly for timeseries data.\nThese are searched within the input directory specified in the settings file.\n\nFurthermore, 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.\nThe 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.\n\nConcerning computational effort, REVOL-E-TION relies heavily on single core computing power for each scenario and uses significant memory, especially in the 'go' strategy.\nTo 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.\n\n#### Common Problems \u0026 Troubleshooting\n| Error message | Cause | Solution |\n|----------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Errors while installing the required Python packages | various | Make sure to start with a clean Python environment using Python \u003e=3.11. We recommend conda for dependency resolution. |\n| Gurobi related installation \u0026 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. | \n| ```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) |\n| ```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. |\n| ```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) |\n| 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. |\n\n\n## General Terms \u0026 Definitions\nThe following table details common terms occuring in further descriptions and the code:\n\n| Term | Description |\n|-----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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. |\n| 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. |\n| 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. |\n| 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\". |\n| 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: ![Rolling Horizon principle](./images/rolling_horizon.png) |\n| 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. |\n| Component | A component is an oemof element that is either a source, a sink, a bus, a converter or a storage. |\n\n## Classes of Blocks\nThe 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.\n\n| Class Name | Description |\n|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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. |\n| 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. |\n| 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. |\n| FixedDemand | Class for undeferrable (i.e. inflexible) power demand such as households. Child of class Block. Power timeseries is defined in a csv file. |\n| 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). | \n| 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. |\n| ControllableSource | Class for independently controllable power sources (e.g. fossil generator, hydro power plant) that is unlimited in energy. Child of class InvestBlock. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| BatteryCommoditySystem | Class for fleet of mobile batteries. Child of class CommoditySystem. |\n| ICEVSystem | Class for comparative calculation of ICEV fleet cost. \n\n## Settings Input Parameters\nThe settings file defines all common parameters for the scenarios in a simulation run.\nIts structure is much simpler than with the scenario file.\nThe following table specifies each parameter of a complete settings file, all of which are required for every run.\n\n\u003c!ENTRY_POINT_SETTINGS_TABLE\u003e\n\n| Parameter | Type | Description | Valid values or format |\n|-------------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|\n| solver | str | Name of the solver to be used by pyomo for linear optimization | Tested: ['cbc', 'gurobi', 'gplk'] |\n| 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'] |\n| 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[ |\n| 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 |\n| 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 |\n| save_results_timeseries | bool | Trigger whether to save the result timeseries (separately for every scenario) into the selected or default result directory. | ['True', 'False'] |\n| 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'] |\n| 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'] |\n| 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'] |\n| 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'] |\n| 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'] |\n| dump_model | bool | Trigger whether to save a .lp file containing the mathematical optimization model for later solving through pyomo. | ['True', 'False'] |\n| 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'] |\n\n\u003c!EXIT_POINT_SETTINGS_TABLE\u003e\n\n## Scenario Input Parameters\nThe scenario file defines all noncomplex (i.e. integer, float, string, boolean) parameters of the scenarios.\nComplex (multidimensional) parameters are mostly defined through links to other files (by filename) in the scenario file.\nThe following table specifies each parameter for each possible block class in the scenario file.\nIf and only if a block of a certain class exists within the scenario are these parameters required and read in. \nTherefore not every scenario file contains all possible parameters.\nMultiple scenarios can be defined as multiple columns.\nThe first row (header) of each scenario column defines the scenarios name.\nBy adding a '#' to the start of the name of a scenario column, the scenario is ignored during the simulation process.\nThe first column of the scenario file defines the name of the block the parameter in the second column applies to.\nAn example scenario file is provided in the ```./example``` directory.\nAs 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. \n\n\u003c!ENTRY_POINT_SCENARIOS_TABLE\u003e\n\n| Block | Key | Name | Type | Description | Valid values or format |\n|-------------------------|-----------------------|------------------------------------------------------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|\n| 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' |\n| | timestep | Time step | str | Time step used for the simulation | formats compatible with pd.to_timedelta() such as '15min' or '1H' |\n| | 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' |\n| | prj_duration | Project duration | int | Project duration in years to which the economic results of the simulation duration are extrapolated | [1, inf[ |\n| | 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' |\n| | strategy | Strategy | str | Optimization strategy | 'go' or 'rh' (global optimum, rolling horizon) |\n| | len_ph | Prediction horizon length | int | Length of the prediction horizon in hours. Neglected for every optimization strategy other than 'rh' | [1, inf[ |\n| | len_ch | Control horizon length | int | Length of the control horizon in hours. Neglected for every optimization strategy other than 'rh' | [1, inf[ |\n| | 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 |\n| | 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 |\n| | wacc | Weighted average cost of capital | float | Weighted average cost of capital: discount rate for future expenses/revenues and energies per year | [0, 1] |\n| | currency | Currency | str | Currency used to display results of economic calculations. No influence of calculation itself, only used for displaying. | e.g. 'EUR', 'USD' |\n| | 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] |\n| | 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] |\n| | cost_eps | Epsilon costs | float | Cost added to some flows in order to disincentivice circular flows | [0, inf[ |\n| | 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\" |\n| | 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'}' |\n| 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' |\n| | 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 |\n| | 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 |\n| | 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' |\n| | 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' |\n| | 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 |\n| | 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 |\n| | 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' |\n| | 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[ |\n| | 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[ |\n| | 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[ |\n| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |\n| | 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[ |\n| | eff_dcac | DC/AC efficiency | float | Efficiency of the DC/AC converter in the SystemCore | [0, 1] |\n| | eff_acdc | AC/DC efficiency | float | Efficiency of the AC/DC converter in the SystemCore | [0, 1] |\n| 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'} |\n| | 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[ |\n| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |\n| | crev_spec | Specific customer revenue | float | Specific customer revenue for consumed energy in currency per Wh | [0, inf[ |\n| WindSource | size_existing | Existing size | float | Installed rated power of wind turbine in W | [0, inf[ |\n| | 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 |\n| | 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 |\n| | invest | Investment | bool | Enable additional investment into the wind turbine | True, False |\n| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |\n| | 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' |\n| | height | Height | float | Hub height of the wind turbine in meters | [0, inf[ |\n| | 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 |\n| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed rated power in W | [0, inf[ |\n| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed rated power in W | [0, inf[ |\n| | 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[ |\n| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |\n| | 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[ |\n| | eff | Efficiency | float | Efficiency of the wind turbine | [0, 1] |\n| PVSource | size_existing | Existing size | float | Installed peak power of the pv array in in Wp | [0, inf[ |\n| | 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 |\n| | 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 |\n| | invest | Investment | bool | Enable additional investment into the PV system | True, False |\n| | 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' |\n| | 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 |\n| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |\n| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed peak power in W | [0, inf[ |\n| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed peak power in W | [0, inf[ |\n| | 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[ |\n| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |\n| | 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[ |\n| | 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] |\n| ControllableSource | size_existing | Existing size | float | Installed rated power of the source in W | [0, inf[ |\n| | 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 |\n| | 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 |\n| | invest | Investment | bool | Enable additional investment into the power source | True, False |\n| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |\n| | capex_spec | Specific capital expenditures | float | Specific capital expenditures: cost in currency per installed power in W | [0, inf[ |\n| | mntex_spec | Specific maintenance expenditures | float | Specific maintenance expenditures: cost in currency per year per installed peak power in W | [0, inf[ |\n| | 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[ |\n| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |\n| | 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[ |\n| | eff | Efficiency | float | Efficiency of the source | [0, 1] |\n| 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' |\n| | 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 |\n| | 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 |\n| | 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[ |\n| | 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' |\n| | 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 |\n| | 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 |\n| | 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[ |\n| | system | System | str | The bus (AC or DC) the block is connected to | 'AC', 'DC' |\n| | peakshaving | Peakshaving | str | Peakshaving period. Peakshaving can be deactivated by setting this parameter to 'None' | 'None', 'day', 'week', 'month', 'quarter', 'year' |\n| | 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[ |\n| | 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[ |\n| | 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[ |\n| | ls | Lifespan | float | Lifespan of the block in years after which it will be replaced | [1, inf[ |\n| | 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[ |\n| | eff | Efficiency | float | Efficiency of the grid connection ","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftumftm%2Frevol-e-tion","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftumftm%2Frevol-e-tion","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftumftm%2Frevol-e-tion/lists"}