Aller au contenu principal
This page is not translated yet. Français is switched on so the navigation and URLs can be tested; the text below is the English original. Use the language selector in the header to switch back, or see the documentation home.

DOE & Parameter Sweeps

how-to · Reviewed 2026-07-30 · FEAT-0048 GA

A DOE job runs your simulation many times across a range of input parameters: one parent job, one child run per combination. Use it for parameter sweeps, sensitivity studies, and cross-product exploration.

You supply a templated input file and a list of variables to vary; Rescale does the fan-out. Everything else (software, hardware, licensing) works as it does for a basic job.

Setting up a DOE job​

A DOE job adds two pieces to the standard job setup: variable definitions on the Parallel Settings step, and a templated input file on the Templates step. Everything else (software, hardware, licenses) works the same as a basic job.

  1. On the Jobs page, click Create New Job.
  2. On the Setup step, open the Job Type dropdown and select DOE.
  3. Upload your input files as usual.
  4. Configure variables on Parallel Settings (see below).
  5. Upload your templated input on Templates (see below) and set the Processed Filename to the path your solver expects to read.
  6. Pick software, hardware, and licenses, and submit.

Rescale then launches one child run per parameter combination under a single parent job.

Defining variables in Parallel Settings​

You have two ways to specify the parameter space.

  • Specify your variables here. Define each variable inline with a minimum, a maximum, and an increment. Pick Cross Product to run every combination, or a run-by-run pairing when you want explicit tuples.
  • Use a run definition file. Upload a CSV where each row is one child run and each column is one variable. Use this when your sweep is irregular, externally generated, or too large to configure inline.

Variable names in Parallel Settings must match the placeholders you use in the template file.

Writing a template file​

A template file is your usual solver input with the varying values replaced by ${variable} placeholders. At runtime, Rescale substitutes each variable for its per-run value and writes the result to the Processed Filename you configured on the Templates step.

A minimal Fluent example:

/file/rc tjunction_doe.cas
/file/set-batch-options no yes yes no
/define/bc/vi inlet_cold ,,,,,,,, no , ${cold_temp} ,,,,,
/define/bc/vi inlet_hot  ,,,,,,,, no , ${hot_temp}  ,,,,,
/solve/iterate 500
/file/wcd tjunction_doe%i.cas.gz
/exit yes

The variables cold_temp and hot_temp in this template must both be defined in Parallel Settings. Some solvers can produce templated journal files for you; use those when available rather than editing by hand.

Each child run starts with a fresh filesystem, so your template and post-processing script should not assume state from a previous run.

Inspecting a DOE before you burn core hours​

Parameter sweeps get expensive fast. Rescale provides a template dry run so you can validate the setup before submitting the real job.

  1. Configure the DOE job as you normally would.
  2. Before submitting, select Template Dry Run.
  3. Click Submit.

Rescale flags the submission with the message This is a template dry run - not a real job and populates the Results tab with the full list of child runs. Each child run shows the variable values it would use. Verify:

  • The number of child runs matches what you expected for your cross product or run definition file.
  • Variable substitution looks correct in each child run.
  • Processed filenames point where your solver expects.

When the dry run looks right, clone the job, turn off Template Dry Run, and submit.

Post-processing a DOE job​

For post-processing you typically want a single script that parses each child run's output, extracts the metrics you care about, and consolidates them into one result table or visualization. Because every child run starts with a clean filesystem, you can rely on consistent paths across runs.

Two patterns are common.

  • Post-process script on each child run. Runs in parallel with the child, produces a small artifact per run, and leaves aggregation for later.
  • Post-process script on the parent job. Runs after all children complete and walks the child run outputs to produce a combined view.

You can attach post-processing scripts via Automations rather than rebuilding them per job.

Common parameter patterns​

The most common sweep patterns Rescale users run.

  • Cross product across two or more variables (for example, x velocity from 20 to 30 and y velocity from 3 to 6 in increments of 1, evaluated across 44 runs for an airfoil lift-to-drag study).
  • Explicit run table via a run definition CSV, for irregular sweeps or Latin hypercube samples generated externally.
  • Monte Carlo probability distribution sweeps, where each variable draws from a distribution rather than a uniform range. See the KB article on Monte Carlo probability distribution methods linked below for supported distributions.

Tutorials and worked examples​

The Rescale KB and tutorials library has full end-to-end DOE walkthroughs.

A note on licensing and hardware selection​

License queuing is not recommended for DOE jobs

DOE jobs fan out into many parallel child runs, each consuming license tokens. License queuing, which holds a job until the full token count is available, does not behave well when the parent spawns many simultaneous demands. If you are license-constrained, size your DOE or stagger child runs rather than relying on queuing. See Intelligent Resource Automation for the full license queuing documentation.

On Demand Economy (ODE) is not recommended for DOE jobs

DOE jobs run many parallel child runs that need to complete for your parameter sweep to finish. On Demand Economy uses spot or preemptible cloud instances that can be interrupted mid-run, which disrupts your sweep and wastes the work already done. Use On Demand Priority hardware for DOE jobs to avoid preemption. See the KB article on Understanding On Demand Economy vs On Demand Priority for more details.