Simulation Studio

The Simulation Studio is Roovie's batch simulation workspace.

It transforms simulation execution from a one-building-at-a-time process into a durable, server-side queue system. Operators create reusable simulation profiles, queue buildings from across the portfolio, configure execution parameters, and launch. The server processes buildings independently — one failure does not stop the queue, the browser can be closed without losing progress, and failed items can be retried.

This is how simulation works at portfolio scale.

In One Line

Create a profile. Queue buildings. Launch. The server runs them all — with retry, scheduling, and per-building control.

How It Works

Create or select a simulation profile
  → Configure batch defaults (date range, physics, output, weather)
  → Add buildings to the queue (search, filter, or add by group)
  → Apply per-building overrides where needed
  → Set execution mode (concurrent or sequential) and scheduling
  → Launch the batch
  → Server processes buildings independently
  → Monitor progress in real time
  → Retry failures or cancel remaining items

Simulation Profiles

A simulation profile is a reusable template that captures all the settings needed for a consistent simulation run.

What A Profile Contains

• Request defaults: date range, output flags (save results, full results, hourly data, monthly summaries), aggregation options, physics modes, TDV calculation settings, variable selection
• Weather strategy: use each building's city weather or a fixed weather file for all buildings
• Execution defaults: concurrent or sequential mode, maximum concurrency, retry count, retry backoff delay, and scheduling type
• Naming template: pattern for generated simulation names using variables like building name, profile name, and timestamp

Profile Management

• Create profiles with descriptive names like "Utility Baseline Annual" or "Monthly Calibrated Re-run"
• Update existing profiles as requirements evolve
• Delete unused profiles — queue rows that referenced them fall back to batch defaults
• Profiles are organization-scoped and reusable across unlimited batches

The Workspace Draft mode allows operators to configure settings for a one-off run without saving a profile.

Building the Queue

Adding Buildings

Buildings are added to the queue by:

• Text search: filter the building list by name, city, or state and click to add
• Building group: select a group and add all its buildings in one click
• Filtered add: add all buildings currently visible after filtering

The queue deduplicates automatically — adding a building that is already queued has no effect.

Per-Building Overrides

Most buildings in a batch use the same profile settings. For the exceptions, per-building overrides provide granular control without creating a separate profile.

Each queue row can independently override:

• Profile selection — use a different profile than the batch default
• Weather source — switch between per-building city weather and a fixed weather file
• Date range — different start and end dates
• Naming template — different naming convention

Override indicators show which rows have custom settings, and a clear button reverts any row to the batch defaults.

Settings Precedence

When the server resolves what settings to use for a building, it follows a clear hierarchy:

1. Row-level overrides (highest priority)
2. Batch-level defaults
3. Profile defaults
4. Building/location fallback (lowest priority — building's city for weather, for example)

This mental model answers the question "why does Building X differ from the group?" — check if it has a row override or different profile.

Execution Configuration

Mode

• Concurrent: multiple buildings simulated in parallel, up to a configurable maximum (1 to 50, default 3)
• Sequential: one building at a time, in queue order

Retry

• Retry count: 0 to 5 automatic retries on transient failures (default 1)
• Retry backoff: delay between retries in milliseconds (default 30 seconds)

Transient failures — network timeouts, temporary service unavailability, server errors — are retried automatically. Non-transient failures (invalid building data, missing required fields) are logged but not retried automatically.

Scheduling

• Run now: items begin processing immediately after launch
• Start at: items remain scheduled until a specified date and time, then begin processing
• Windowed rate: items are released over a time window at a controlled rate (for example, 12 per hour), useful for very large portfolios where API throttling is a concern

Launch and Monitoring

Launching

Click Launch. The system creates a persisted batch record and one batch item per building. The server's queue worker begins claiming items based on the execution configuration. The UI switches to the Active Batch monitoring view.

Real-Time Monitoring

The monitoring panel updates every 10 seconds while the batch is active:

• Summary cards: overall batch status, counts by item status (scheduled, queued, running, completed, failed, cancelled), and last activity timestamp
• Configuration snapshot: execution mode, concurrency, schedule type
• Status filter tabs: filter the item list by status to focus on what needs attention
• Item list: each item shows building name, status badge, attempt count, simulation ID (if completed), error message (if failed), and latest log entry

Failure Handling

Each building is processed independently. One building's failure does not stop or delay the others. The batch continues until all items have completed, failed, or been cancelled.

Failed items show specific error messages with context: engine errors, weather resolution problems, invalid building payloads, transient network issues. Each failure is timestamped and logged.

Retry and Cancel

• Retry Failed: re-queues all failed items for another attempt. Successfully completed items are not affected.
• Cancel Batch: stops processing queued items. Items currently running may finish. Future items are marked cancelled.

Durability

The batch is server-side and persistent:

• Closing the browser does not lose the queue or stop processing
• Refreshing the page restores the full UI state
• Returning to the Studio later shows the batch in the Recent Batches list
• Up to 8 recent batches are visible for quick resume

Weather in Batches

Three modes are available:

• Per-building city weather: each building uses the weather data for its registered city. This is the default and most common mode.
• Fixed weather file: all buildings use the same weather file. Useful for standardized compliance runs or what-if scenarios.
• Row-level override: individual buildings can use a different weather source than the batch default.

Naming Templates

The naming template controls what generated simulations are called. It supports three variables:

• {buildingName} — the building's name
• {profileName} — the active profile's name (or "Workspace Draft")
• {timestamp} — ISO timestamp at simulation creation

The default is "{buildingName} - {profileName} - {timestamp}". Custom templates can be set at the batch level or per-row.

Output Configuration

The batch defaults panel exposes the full set of simulation output options:

Core Output

• Save results to database
• Include full aggregated results
• Enable ASHRAE 140 validation mode
• Exclude hourly results for faster, smaller output

Aggregation

• Aggregate windows by orientation (N/E/S/W)
• Aggregate walls by orientation
• Aggregate surfaces for physics optimization

Result Format

• Compact hourly format
• Exclude per-assembly hourly data
• Exclude per-zone hourly data
• Calculate TDV (Title 24 compliance)
• Include daily, weekly, and monthly summaries

Physics Modes

• Surface film mode: dynamic, static, or auto
• Solar irradiance model: Perez, isotropic, or ASHRAE blend

Downstream Integration

Simulation Studio feeds directly into downstream workflows:

• Calibration: batch-generated baseline simulations are used for shared meter allocation and ASHRAE Guideline 14 calibration
• Comparison: batch results enable before-and-after ECM analysis across the portfolio
• Reporting: completed simulations feed portfolio dashboards and performance summaries
• Investment planning: simulation results drive the priority scoring and financial analysis in the CFO engine

The Studio is not an isolated tool. It is the execution layer that populates the portfolio with simulation data that every other workflow depends on.

What Makes This Different

Most simulation tools process one building at a time. Running a portfolio requires launching each simulation manually, babysitting the process, and manually tracking successes and failures.

Roovie's Simulation Studio is different:

• Profiles capture simulation methodology as a reusable, shareable template
• The queue handles hundreds of buildings with per-building override capability
• Execution is server-side — the browser can be closed
• Failures are isolated and retryable, not queue-stopping
• Scheduling supports delayed start and rate-limited execution for large portfolios
• Settings precedence is explicit and auditable (row > batch > profile > building)
• Results integrate directly into calibration, reporting, and investment planning

The Studio transforms simulation from a manual, one-at-a-time task into an operational workflow that scales to any portfolio size.

Bottom Line

The Simulation Studio is how Roovie runs simulations at scale. Operators define reusable profiles, queue buildings, configure execution, and launch. The server processes buildings independently with retry, scheduling, and failure tolerance. Results feed directly into calibration, comparison, and portfolio planning.

It is the bridge between having a portfolio of building models and having a portfolio of simulation results — the data foundation that every downstream analysis depends on.