Scenario

Scenarios are collections of model components and simulation runs.

Scenario loading

To load a scenario, click on one in the dashboard or create one within a project. The loaded scenario name can then be seen in the header on the left side. Within a scenario, the routes to its inputs, outputs, and simulations are available in the navigation bar.

Scenario creation

To create a new scenario, click on Create scenario at the project overview and choose the scenario name and year. The default simulation horizon is one calendar year. If required, please define another simulation horizon in the range of one hour and multiple years. Please be aware that the results may be limited in comparison, if the simulation horizons are different.

During creation, the parent scenario can be selected. If any other scenario is chosen as a parent scenario, the newly created scenario inherits the components of the parent scenario.

Scenarios can be classified as base or inherited scenarios. If a scenario does not have a base scenario (i.e., is not inherited from another scenario) then it is a base scenario. Base scenarios can be used for stand-alone scenarios or as the base scenario for a scenario tree.

Scenario manipulation

After loading a scenario, the top navigation bar appears. The top navigation bar provides features for inputs, simulations, and outputs of the loaded scenario.

Scenarios comprise component data (see input). Components can be imported and exported through the input routes provided in the top navigation bar. Alternatively, components can be filtered, sorted, created, edited, disabled, enabled, and deleted directly in the frontend. Time series values and characteristics such as capacities, work, and full load hours can be adjusted the input routes.

Bulk edit enables operations like delete, enable, or disable to be applied on all entities.

Input datasets can be attached with optional metadata like geographic information (see metadata). By providing geographic information to single components, map-based visualizations and edit possibilities are enabled via OpenStreetMap. The maps utilize the auxiliary fields lon_aux and lat_aux describing the longitude and latitude of single components.

Under simulation, the scenario can be run for different market simulations (see procedure).

Under output, outputs of completed runs can be analyzed (see result analysis).

Inheritance

Inheritance is a feature that helps reduce data redundancy by over 99% on average, which significantly speeds up market simulations.

Inheritance function

Components can be valid and, independently, enabled, as illustrated in the figure below. Only components that are both enabled and valid are used in the simulation. A component is enabled if this property is set to true. A component is valid if the scenario year falls between its commission and decommission years, including those years themselves.

The auxiliary property enabled_aux of a component determines whether it is enabled or disabled. The commission and decommission years can be defined using the properties year_commission_aux and year_decommission_aux. If these properties are not specified, the component is considered enabled and valid for all scenario years.

Individual components represent subsets of the input data and fully inherit into subsequent scenarios when enabled, as shown in the figure below. This inheritance ensures that components remain consistent across scenarios.

To model commission and decommission events during the year, the component needs to be set in must-run, revision, or outage. This event with zero maximum power can cover the time range before the commission interval in the commission year and the time range after the decommission interval during the decommission year.

Inheritance granularity

Following sub-sets of the scenario input data constitute one single component that can be inherited.

Inheritance is always active and propagates through the scenario tree. Any modifications to origin components automatically apply to all scenarios inheriting from them, unless explicitly overwritten.

To break the inheritance for a single component, the component can be disabled in the according scenario. In this case, changes in the origin component do not affect the subsequent scenario (where disabled) and do not affect sub-subsequent scenarios. But, newly created components always inherit in the subsequent and sub-subsequent scenarios. Inherit breaks also occur if one inherited component in a subsequent scenario is edited in any way. Then the edited component is copied in the current scenario, two origins are set and so changes in the previous origin do not inherit anymore (where copied).

Component changes should usually affect the whole scenario tree and should be made in the origin scenario. Thereby, scenario sequences can be built consistently with each other in time and system dimensions. Plus, the parametrization workload can be reduced to a minimum since multiple scenarios are edited at once.

Additionally, origin components can be deleted. Deleted and deactivated components have the same result, except that disabled components remain in the input data and can be enabled later. Deleted components cannot be restored.

Input import

To import data into the cloud, the import data check needs to be fulfilled. Otherwise, the import will be canceled and an error description provided. This input import data check covers the following.

• File re-formatting (remove byte order mark, convert to LF UTF-8, etc.)
• Alignment of data types (interval number, integer, float, string, technology, etc.)
• Alignment of the data format (date format DDMMYY@HH:MM, interval number, etc.)
• Adjusting formatting (removing leading spaces or breaks, etc.)
• Correct Id settings
• Relations between components like plant to existing bidding zone or reservoir to turbine

The import includes first data format and consistency checks, but does not guarantee the full consistency as the data check to enable parallel and cross-workflows. Please check the error messages for all imported files. Data is only imported, if zero import errors occur. Please note therefore also file header specifiers (see input). Depending on the difference between database and importing file following database changes can be carried out.

• Create new components through importing components via leaving ids blank (component id must be not given)
• Edit components through exporting, changing component parameters except the id and importing again (component id needs to be set)
• Disable components through exporting, setting the enabled flag enabled_aux in the file to false and import again (component id needs to be set)
• Delete all components through click on delete in front-end

In case of successful imports of new components without ids such new components receive a unique hash id that definitely describes it. That id can be seen afterwards in the according file export or graphical user interfaces and can be used for subsequent edits. During the import of data, identical datasets (e.g., via file check sums) is automatically re-ordered and redundancies identified, thus reducing duplicates in the database.

Input export

The export comprises the current valid input data inclusive inherited and disabled components. Datasets can reach significant amounts. However, the data export can be filtered in the front-end. All entries can be exported with their corresponding unique component IDs.

Autobuilds

Autobuild provides an automated generation method of dummy components to reach power sums per bidding zone for example from publicly available scenarios. This allows power sums to be broken down into concrete and detailed commissioned and decommissioned units. During autobuild, the user receives a proposal and can add specific assumptions and edit the dataset afterwards using the provided interfaces.