Nastran Performance & Run Control Files

Engineering Tools — Nastran Performance & Run Control Files

Why this page exists

Stress engineers running Simcenter Nastran (or any MSC-lineage Nastran) on modern workstations routinely leave performance on the table because the default launch behavior — nastran.exe job.bdf with no flags — uses whatever the global nastran.ini says, which is usually smp=1, mem=2GB. Fine for tiny jobs; a real cost on anything production-scale.

This page walks through the two ways to feed Nastran options, the Run Control File syntax, the two configurations of work that determine which knobs matter, and what an in-house SMP sweep on a representative modal-extraction deck (~1.26M grids, 80 GB memory budget) actually showed.

The two ways to pass options to Nastran

You can pass Nastran keywords either inline on the command line or via a Run Control File:

  nastran.exe job.bdf smp=4 mem=8gb scr=yes old=no
  nastran.exe job.bdf rcf=path\to\settings.rcf

The Run Control File is a plain text file with one keyword per line:

  mem=8gb
  smp=4
  scr=yes
  old=no
  estimate=no

Both forms accept the same keywords. The Run Control File is the preferred workflow once you have more than two or three options to manage, because you can version-control the file alongside the deck, point multiple jobs at the same master file, and avoid 200-character command lines.

The two configurations that actually matter

For day-to-day work, every Nastran job belongs to one of two configurations. Picking the right one before launch matters more than any individual keyword tuning.

Configuration 1 — Single large stream

One job at a time, all of the machine's resources on it.

• When to use: production solves of large models, long modal extractions, transient and frequency response, anything that produces tens or hundreds of GB of scratch.
• Symmetric MultiProcessing setting: smp=4 to smp=8. See the SMP sizing section below for the curve shape on real workloads.
• Memory setting: run estimate=yes first, then set mem= to roughly 1.2–1.5x the estimate. More memory means less scratch I/O during the solve.
• Scratch device: the fastest disk you have, ideally NVMe. Large modal and transient solves are scratch-I/O-heavy and the device speed shows up directly in wall time.
• Parallel streams: zero. Nothing else runs concurrently. The machine is a single-purpose computer for the duration.

Configuration 2 — Parallel small streams

Multiple independent jobs running concurrently, each with a slice of the machine.

• When to use: trade studies, parameter sweeps, load-case matrices, design iteration — anything where you have a queue of jobs that don't depend on each other.
• Symmetric MultiProcessing setting per job: smp=4 by default; consider smp=2 if you want to fit more streams.
• Number of streams: bounded by two ceilings, whichever is lower:
  1. Available RAM ÷ per-job mem= with headroom for the operating system (target ~75% utilization, not 100%).
  2. Number of Nastran tokens on your license. Most license seats are per-process; four parallel jobs need four available tokens.
• Total core utilization: on a 16-core machine with enough RAM and licenses, 4 streams × smp=4 = 16 cores fully loaded and four jobs done in the wall-clock time of one. The Engineering Tools Femap Re-Translator and Run Nastran Jobs in Series tools both support this pattern.
• Scratch device: still matters — multiple streams share scratch I/O bandwidth, so an NVMe still pays. If scratch is on a spinning disk, drop the stream count.

Which configuration am I in?

Quick heuristic: run the deck through estimate=yes first (it's seconds, even for big models). Then ask:

• Do you have one big job in front of you? → Configuration 1. All memory, fastest scratch, smp=4 or smp=8.
• Do you have many small jobs in a queue? → Configuration 2. Tile parallel streams within available RAM and license tokens.

Run Control File keywords you'll actually use

The recommended workflow for any non-trivial job

1. Drop the bdf in a work folder.
2. Run with the estimate_only.rcf sample first:

   nastran.exe job.bdf rcf=estimate_only.rcf

   The run finishes in seconds. Look at the resulting .log for two UIM messages:
   • UIM 4157 — memory the real run would need.
   • UIM 6361 — scratch the real run would need.
3. Edit your real Run Control File so mem= is at least the UIM 4157 value plus 20% headroom. Confirm your scratch device has the UIM 6361 value plus a comfortable margin.
4. Launch the real solve. Walk away.

Symmetric MultiProcessing sizing — what the curve actually looks like

Set smp=4 as the default for static and modal runs. Going higher rarely beats it by much on modern Intel or AMD workstations; the wall-time-vs-cores curve flattens around 4–8 cores for typical finite element problems, and Nastran caps some of its parallel modules at 8 processes regardless of what you ask for.

Concrete numbers from an in-house SMP sweep on a ~1.26M-grid modal-extraction deck, run on a 16-core Xeon workstation with mem=80gb held constant across all settings (so the only variable was smp):

Two non-obvious things stand out in that table:

• Most of the available SMP speedup is captured by smp=2 or smp=4. Going from smp=4 to smp=16 buys an additional ~10% wall-time reduction — not nothing, but a long way from linear.
• smp=8 is actually slightly slower than smp=6 on this workload. Nastran's parallel sparse decomposition (P-SDCMP) module caps at 8 processes; once you're there, adding more SMP cores spreads the same eight-process work plus non-parallelized modules across more threads with some context-switch overhead. The minimum on this curve sits at smp=6.

Practical recommendation: for jobs of this scale, smp=4 through smp=8 is the useful range. Going to smp=16 is only worth it if you have idle cores you don't need for anything else; it doesn't buy you proportional wall time. If you have spare cores after picking smp=4 for a job, the better move is usually not to push that job's smp higher — it's to launch a second job in parallel (Configuration 2 above).

GPU acceleration

Setting gpgpu=yes in the Run Control File enables Nastran's CUDA / OpenCL acceleration path. In the current generation of Nastran, this is mostly relevant for the sparse-matrix factorization step of linear-static SOL 101 on very large problems (5M+ degrees of freedom). The GPU pair in the SMP sweep above didn't complete — the test workstation didn't have a GPGPU license token or a CUDA-capable card — so we don't have an in-house number to share either way.

Off by default in the shipped sample Run Control Files. Flip it on case by case if you have the licensing and want to try it on a known solver-bound deck. If estimate=yes says your job is scratch-I/O bound, GPU won't save you.

Memory and scratch — standard guidance

Industry experience consistently says: for big modal and transient runs, the dominant cost is reading and writing scratch files, not the floating-point work in the solver. The implications:

1. Run estimate=yes first. The UIM 4157 and 6361 lines tell you what the real run will need.
2. Set mem= generously. Every extra GB of memory budget is a GB of scratch I/O Nastran doesn't have to do. A common rule of thumb is to set mem= to roughly 1.5x what estimate=yes reports, if RAM allows.
3. Move scratch to NVMe if it isn't already. Sustained sequential bandwidth of a modern NVMe drive is several GB/s; SATA SSD is roughly 500 MB/s; a spinning disk is well under 200 MB/s. For a job that moves hundreds of GB through scratch, this is wall-time visible.
4. Keep scratch and output on separate physical devices if you can. Concurrent reads (scratch) and writes (op2 / f06) compete for device bandwidth otherwise.
5. Then tune smp.

The in-house SMP sweep above held memory constant on purpose, so it doesn't put a number on how much the mem= setting matters on its own. A dedicated mem sweep is on the list.

Sample Run Control Files shipped with Engineering Tools

Located in the Engineering Tools install under _dev/sample_rcfs/. Copy one next to your bdf, edit, and point the Femap Re-Translator or Run Nastran Jobs in Series tools at it.

• default_workstation.rcf — safe defaults for a single job on a typical workstation (mem=16gb, smp=4). Configuration 1 starting point.
• estimate_only.rcf — estimate=yes, no actual solve. Always run this first on any job expected to take more than 30 minutes.
• big_job_high_memory.rcf — mem=32gb, smp=4, scratch kept for restart. Configuration 1 for very large modal or transient runs.
• quick_check_low_resource.rcf — mem=2gb, smp=1, minimal footprint. Use for smoke-testing decks or sanity-checking syntax before the real run.
• parallel_stream_unit.rcf — per-stream Run Control File for Configuration 2; smp=2 so four parallel streams × smp=2 = 8 cores total without oversubscribing.

Using these from inside Engineering Tools

Two Engineering Tools scripts launch Nastran:

• Femap Re-Translator (tool ID 00018) — translates the current Femap model to bulk data, then launches Nastran. /help/00018
• Run Nastran Jobs in Series (tool ID 00003) — batches an existing list of bulk decks through Nastran sequentially. /help/00003

Both tools accept a Run Control File path in their dialog and append it to the Nastran command line. For parallel-stream operation (Configuration 2), Run Nastran Jobs in Series can be pointed at the same deck list from multiple shells, each one with its own Run Control File — the tool locks per-deck so the same job never gets picked up twice.

Quick reference card

Engineering Tools is licensed under the Apache License, Version 2.0. Modifications and contributions welcome via contribute@engineeringtools.org.