Scenario

Scenario management

The selected scenario can be seen in the header on the left side. Scenarios can be distinguished between root scenarios and inherit scenarios. If a scenario does not have a base scenario (is not inherited from another scenario respectively has no parent scenario assigned) then it is a root scenario. Root scenarios can be used for stand-alone scenarios or as the root scenario for a scenario tree.

To set up a new scenario click on create scenario at the project edit route and choose the scenario name and the scenario year. The default simulation horizon (whole simulation period) is one calendar year. If required, please define another simulation horizon in the range of two hours and multiple years. Maon can handle different calendar definitions, including real time calendar and 52 weeks calendar. Please be aware that the results may be limited in comparison, if the simulation periods lengths are different.

Inheritance concept

So-called components or sub-sets of input data are inherited in subsequent scenarios like the following picture shows. Components inheritance is given, if the year of a subsequent scenario intersects the components valid time span. The commission and decommission years of a component can be set via the auxiliary fields year_commission_aux and year_decommission_aux. If none are given, the component is inherited for all years.

Components are assumed fully available during the commission and the decommission year. To model commission and decommission events during the year, the component needs to be set in must-run. This must-run with zero maximum power should cover the time range before the commission event in the commission year and the time range after the decommission event during the decommission year.

Inheritance granularity

Following sub-sets of the scenario input data constitute one single component that can be inherited. Bidding zones and their configuration inherit for all years.

Components existing in a scenario is defined through the component validation time stamps. If time stamps are used as hour numbers (1, 2, 3, …) it is inherited for all years between the commission and decommission year as well as for the commission and decommission year. In case of from and until time stamps (DDMMYY@HH:MM) of a component the component is only valid in the exact time stamp and is so only inherited if the inherited scenario has the same simulation year. Inheritance is always activated and continues recursively through the scenario tree. Any change of origin components will result in the same change in all this component inherit scenarios.

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 therefrom 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 kind. 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).

Single component changes should usually affect the whole scenario tree and should therefore made at the origin. Multiple changes - especially to integrate scenario assumptions like the hard coal power sum per bidding zone from TYNDP 2030 best estimate - should be done in the according scenario in the scenario tree. So scenarios sequences can be build consistently to each other in time and system dimensions. Plus, the parametrization workload can be reduced to a minimum since multiple scenarios can be 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.

Scenario manipulation

Clicking on a scenario in the scenario tree loads the according scenario. The name of the loaded scenario can be seen afterwards on the left upper side of the screen besides the top navigation bar. 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 in the input routes provided in the top nagigation bar. Alternatively, components can be filtered, sorted, created, edited, disabled, enabled and deleted directly in the front-end. Time series inputs can be edited via scaling features. To change values within time series, use the input export and import routes.

Bulk edit enables operations like delete, enable or disable applied on multiple 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.

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 checks and consistency checks, but does not guarantee the full data consistency to enable parallel and cross-workflows (see check). Please check the error messages for all imported files. Data is only imported, if zero import errors occur. Please note therefor 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 sucessful imports of new components without ids such new components receive an 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 the according unique component id.

Autobuilds

Autobuild provides an automated generation method of dummy components to reach power sums per bidding zone for example from public available scenarios. So power sums can be broken down to concrete and detailed constructed and decommissioned units. During autobuild the user receives a proposal and can add specific assumptions and also edit the dataset afterwards with the provided interfaces.