Skip to content

Running simulations

Run Simulation exports the case and launches the solver. This page covers the run path and its pre-flight gate, choosing the CPU or GPU engine, the live telemetry a run shows, where results land when it finishes, and Live mode.

Run Simulation and Preview Mesh

The two actions sit at the top of the left rail. Both need a saved project, and both save a dirty project before they start.

Run Simulation exports the project to a solver case and launches the backend. Before anything launches, the same pre-flight gate the CLI uses (sim.preflight) validates the project. A blocking error refuses the run and names the reason: a port too small for the mesh, a port whose vertical span collapses to zero cells, a collapsed shape that would rasterize blank, an unknown boundary type, a negative air margin, a radiation pattern with no open face. Nothing is silently clamped or recomputed. A warning does not block: it is shown before the run so you decide. The gate also refuses a GPU run whose estimated VRAM exceeds the detected card, and a CPU run whose footprint exceeds free RAM.

Preview Mesh builds the 3D FDTD mesh and shows it without running the solver, so you can check resolution and cell count. It runs the same pre-flight gate first, so a bad port does not silently render an empty mesh. Above about 20 million estimated cells the preview can take minutes to build and render, so it asks before continuing. It never blocks: you always decide. With no mesh estimate yet, it says so in the log and proceeds rather than inventing a number.

GPU and CPU engines

The CUDA GPU backend is the default. At startup the app probes for a compatible NVIDIA GPU. When one is found, its name and VRAM print to the console. When none is found, the run falls back to the CPU backend (OpenMP): the Use CPU backend checkbox locks on for the session and a banner explains the fallback. The same fp32 solver runs on either engine and produces equivalent results to numerical precision. The CPU is significantly slower.

Check Use CPU backend yourself to run on the CPU with a compatible GPU present. Leaving it unchecked with no GPU detected, then clicking Run, raises one dialog offering the CPU fallback, with an option to remember the choice until the GPU hardware changes. A remembered choice is keyed to the GPU fingerprint, so a driver or card change re-prompts.

Selecting a specific GPU by index is a remote and CLI concern only: device_index pins a GPU slot on a multi-GPU remote runner, and a local run refuses it.

Live telemetry during a run

While the solver runs, the title bar shows elapsed time and throughput in GCell/s, and the runtime panel updates in place.

  • Energy Ringdown plots the energy ratio against time step on a log axis, with the stop threshold drawn as a dashed line. The run ends when the ratio crosses it.
  • S-Parameter Convergence overlays the S-parameter estimate from recent passes so you can watch it settle.
  • Runtime Stats reads out elapsed, time step, GCell/s, cell size, ringdown, cell count, RAM, VRAM, and disk. A VRAM overflow raises a warning here.

Two buttons sit below the stats. Pull Snapshot exports the results computed so far without stopping: the solver pauses briefly to write S-parameters, fields, and radiation data, then resumes. The loaded snapshot is marked partial on the ringdown plot and in the result tabs' freshness badge. Stop Early ends the run before the energy criterion, and asks what to do with the work so far: Stop and Keep Results flushes a partial run and keeps it, or Discard All Results throws it away. A kept partial run is recorded as stopped, never as a clean completion.

When a run finishes

A run ends when the energy ringdown crosses its threshold or hits the configured step and ring-down caps, and a capped run is not converged (FDTD tips). Results land in the project: the S-Parameters and Simulate tabs always update, and the Radiation Pattern and Field Viewer tabs update when their outputs were enabled. Each tab that got new output shows a dot until you open it. When the project has result externalization on, the heavy run output is written to a .rfsimout sidecar next to the project instead of inside the .rfsim.

If you edit the geometry or settings after a run, the result tabs show a freshness badge saying the geometry, the config, or both changed since the run produced the data on screen. The badge separates results that still match the current inputs from results that are now stale, so a plot is never mistaken for the edited design. Switching between auto and advanced mode keeps the existing results, and the badge marks them changed only when the effective settings differ from the run.

Live mode

Live mode reruns the simulation automatically as you edit, for fast iteration on small designs. Enter it with the LIVE button in the tab row. The tabs reparent from the tab bar into a 2x2 dock grid: Edit above Simulate on the left, S-Parameters above the Field Viewer on the right, with Radiation tabbed onto the Field Viewer. You can rearrange the grid and the layout persists with the project. Markers placed on the S-parameter plot keep tracking across reruns.

Every geometry or settings edit schedules a rerun after a 120 ms debounce, so a burst of edits fires one run, not one per keystroke. An edit that arrives while a run is in flight supersedes it: the running solver is stopped and relaunched on the newer input, and the superseded run is discarded rather than counted. Live mode auto-runs with no Run dialog, so it falls back to the CPU backend when no GPU was found, and it disables itself after two consecutive failed runs. Leave Live mode with the same LIVE button.

From the command line

rayrf run runs the same solver headless, and rayrf serve and rayrf remote drive runs on another machine. On the Simulate tab, Configure remotes opens the runner manager, and Run remotely with the runner picker beside it submits the run to the picked runner. See Remote overview. The full verb and flag list is in the CLI reference.