Frontend

The graphical user interface is how you operate the Maon Cloud Software. It provides features like settings, dashboard, project management, scenario management, simulation management as well as result data export and graphical analysis. Multiple users can work at the same time on one project or scenario.

Settings

Settings can be divided into personal details, platform settings and project configurations. Personal details and platform settings can be reached in the settings. The project configuration depends on the individual project and can be adjusted in the project management.

Dashboard

The dashboard is the first page occurring after a successful login. It provides an overview of the simulation environment through displaying the projects and runs as well as their storage use and state. On the left side the scenario tree can be displayed and new projects created.

Project management

The scenario tree visualizes all projects on the left sidebar. The left sidebar respectively the scenario tree can be opened via click on the left red punctuation mark (>>) at the dashboard. Projects are highlighted grey and are always in the scenario tree root. To set up a new project or to do project changes, click on Create new project or Edit current project at the bottom of the scenario tree.

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.

Scenario tree

The scenario tree comprises projects and thereto connected scenarios. It can be opened and adjusted through the project management. Through clicking on the plus signs (+) and minus signs (-) in the scenario tree, projects and scenarios can be opened and closed. The structure of scenario trees is organized as follows.

• Tree root: project (every project has its own tree root)
• Scenarios in first level: base scenarios since no components inherited from other scenarios
• Scenarios in second or higher level: derived scenario with scenario parent sequence of at least one parent scenario

Every project has its own project configuration that is applied for all to the project related scenarios. Scenario trees begin always with a base scenario. Therefrom derived scenarios inherit components of the parent scenario. Scenarios can be derived multiple times.

The inheritance feature enables a productive and consistent parametrization, especially for large scenario sets with scenario sequences.

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.

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.

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.

Autobuild

Autobuild provides an automated generation method of dummy power plants to reach generation 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 power plants. During autobuild the user receives a proposal and can add specific assumptions and also edit the dataset afterwards with the provided interfaces.

Simulation management

After a scenario is selected in the scenario tree, the simulation management can be found in the header under Single check and run. After starting Check scenario or Run simulation, the current state of all scenario inputs is exported into the High Performance Cluster (HPC) in the background. The user can check the current status of the run in the simulation management. After a simulation is started, the input dataset can be changed in parallel. To consider such changes a new run must be started.

The result of Check scenario (data check) is displayed in the simulation management and exported into the file stdout.log. The displayed error list includes an understandable error messages and specific recommendations for solving. The version of the software core used to create any outputs is included in the header of stdout.log. After a successful scenario check, the platform runs simulations via Run simulation unattended and uninterrupted, so no manual inputs or popup boxes need to be approved. The simulations run in a HPC with multiple instances running in parallel. Node scheduling, simulation monitoring, result storing and others are fully automated.

After a run ends, the input data and all result files can be downloaded via click on Download output. The market simulation run is successfully, error-free and fully done if the last three lines in stdout.log display the total procedure time.

Two clicks on Delete in the simulation management will delete the according simulation dataset without any possibility for restoration. This does not affect the scenario input data since it is saved independently. So there can be a series of simulation runs (with different inputs) in a single scenario. Runs are shown in start time stamp inverse order in the simulation management list.

Result analysis

The result analysis can be done manually via result files from the simulation management (see simulation management). Alternatively, analysis can be carried out via the toolkit in the front-end. Currently, the following figures are available. All figures are made with the target to compare simulation results visually. All graphs are based on result files and load automatically in several seconds.

• Balances for energy, power, emission and cost including filter for bidding zones and technologies
• Zone-by-zone graphs for generation, consumption, exchanges, spot prices, net positions, unavailable generation capacities, remaining generation capacities, residual loads, fuel consumptions and emissions (for example for 8760 hours in Germany)
• Unit-by-unit graphs for commitments, average cost, marginal cost, hydro flows, hydro filling levels, fuel consumptions (for example for 8760 hours of a single component)
• Social welfare components like consumer rent, producer rent and congestion rent (for all bidding zones)
• Numeric assessments in graphs of thermal power plants, hydro power plants, grid capacities, flexible demand and RES (for all components in a bidding zone)
• Visual assessments in maps of thermal power plants, hydro power plants, grid capacities, flexible demand and RES (for all components)

Additionally, simulation results can be uploaded in the section Output compare so that the simulation result can be compared with the uploaded data in the front-end. Manual analysis of simulation results can also be done through downloading the full output dataset (see simulation management).