Simulation

Simulations are snapshots of inputs and outputs.

Simulations

After a scenario is selected in the scenario tree, the simulations can be found in the navigation bar under Simulation. The different market simulation types are explained under procedure. 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. After a simulation is started, the input dataset can be changed in parallel. To consider such changes a new run needs to be started.

Data check

The result of Check scenario (data check) is displayed in the frontend and exported into the file stdout.log. The displayed error list includes understandable error messages and specific recommendations for solving.

Simulation run

After a successful scenario check, the platform can run 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 successful, 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 list will delete the according simulation dataset without any possibility for restoration. This does not affect the scenario input data. So there can be a series of simulation runs (with different inputs) in a single scenario. New runs are at the top in the simulation list.

Scheduling

The run scheduling is based on slots, which are visible in the dashboard. Slots limit how many jobs a user can run concurrently on the cluster. Jobs that exceed this limit are queued and started automatically when slots become available.

Single-user scheduling

In a single-user scenario, scheduling is only constrained by the slots of a user.

• Each user has a fixed number of slots, defining the maximum number of concurrent jobs.
• If the user submits as many or fewer jobs than available slots, all jobs start immediately.
• If the user submits more jobs than available slots, the extra jobs are placed in a queue.
• Jobs in the queue are processed in submission order.
• As soon as a running job finishes, the next job in the queue is automatically started.

Run order

Jobs are started using a first-come, first-served (FCFS) policy.

Exemplary submission

• Cluster: 3 nodes
• User: 2 slots
• User submits 5 jobs

Exemplary result

• 2 jobs run in parallel.
• 3 jobs wait in the queue.
• As soon as one job finishes, the next queued job is immediately scheduled and started.
• This continues until all jobs are completed.

Cross-user scheduling

In a multi-user scenario, multiple users share the same cluster. To ensure fairness, each user belongs to an organization with a fixed number of slots, which are displayed in the dashboard. Jobs that exceed an organization’s slot limit wait in the cluster queue until a slot for that organization becomes available.

Run order

Each job is either running, or waiting in one of the following two queues:

• Organization queue: All submitted jobs first attempt to enter the organization queue. This queue includes both running and waiting jobs and is limited by the organization’s assigned number of slots.
• Cluster queue: Jobs that do not fit into an organization’s queue are placed in the cluster queue.

This ensures that:

• Users cannot exceed their assigned organization slot limits.
• From a single-user perspective, jobs are executed in first-come, first-served (FCFS) order.
• From a cluster-wide perspective, job execution order depends on the submitting organization’s available slots.

Exemplary submission

• Cluster: 3 nodes
• User A: 2 slots
• User B: 3 slots
• Both users submit in total 5 jobs, with alternating submissions
  • Job 1 by User A
  • Job 2 by User B
  • Job 3 by User A
  • Job 4 by User B
  • Job 5 by User A

Exemplary result

• Immediate execution
  • Job 1 from User A is scheduled on Node 1.
  • Job 2 from User B is scheduled on Node 2.
  • Job 3 from User A is scheduled on Node 3.
  • At this time point, all cluster nodes are occupied, so Jobs 4 and 5 enter the appropriate queue.
• Organization queuing
  • Job 4 of User B cannot start immediately because no cluster node is available.
  • Since User B’s organization is still within its slot limit, Job 4 is placed in User B’s organization queue.
  • Job 4 will start as soon as one of the running Jobs 1, 2, or 3 finishes.
• Cluster queuing
  • Job 5 from User A also cannot start because the cluster is fully utilized.
  • Since User A’s organization reached its slot limit, Job 5 is placed in the cluster queue.
  • Job 5 will be scheduled after Job 4 has started and after either Job 1 or Job 3 finishes, freeing a slot in User A’s organization queue.

This system ensures that organization queues take priority over the cluster queue, maintaining both fairness and slot limits.

Pay-Per-Use vs. Flat-Rate

Pay-Per-Use and Flat-Rate organizations differ in how they share cluster resources.

• Pay-Per-Use: Multiple organizations share a common pool of nodes in one shared cluster.
• Flat-Rate: A single organization has a dedicated pool of nodes in a separate cluster shared only among the users of the organization.

Result analysis

The result analysis can be done manually via result files from the simulation list at the dashboard. 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, emissions and costs, including filters 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 consumption (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.