How out-of-core solving works when a simulation exceeds available RAM, why scratch disk speed becomes a critical bottleneck in that scenario, and how to decide between more RAM and faster storage.
What Happens When a Solve Doesn't Fit in RAM
When a finite element or CFD solver's problem size exceeds available system RAM — a genuinely common situation for large, fine-mesh models on hardware that isn't specifically over-provisioned for the largest anticipated problem — the solver can typically still complete the analysis by running in an "out-of-core" mode, writing intermediate solution data to disk (a dedicated scratch space) rather than holding everything in RAM simultaneously. This lets large problems complete on hardware that couldn't hold the full problem in memory at once, at the cost of solve time.
Why Scratch Disk Speed Becomes the Bottleneck in This Scenario
Once a solver is operating out-of-core, its performance becomes directly gated by how quickly it can write intermediate results to and read them back from the scratch disk — the solver is repeatedly moving substantial volumes of data to and from storage as part of its normal iterative or factorization process, not as an occasional operation. In this specific scenario, storage I/O speed can become as significant a performance factor as RAM capacity or CPU speed, a departure from typical CAD or general computing use where storage speed mainly affects file-open and save times rather than continuous, in-the-loop computation.
Why NVMe SSDs Made a Real Practical Difference Here
Traditional spinning hard drives have relatively poor random-access I/O performance compared to sequential throughput — a genuine problem for solver scratch-disk access patterns, which aren't purely sequential. NVMe SSDs offer dramatically higher random I/O performance (as well as higher sequential throughput) than both traditional hard drives and even earlier-generation SATA SSDs, which is a large part of why out-of-core solving became considerably more practical as NVMe storage became standard on engineering workstations — a large out-of-core solve that would have been painfully slow on a traditional hard drive scratch disk can complete in meaningfully less time on a fast NVMe scratch drive.
The More RAM vs. Faster Storage Tradeoff
Faced with a problem too large to fit comfortably in available RAM, there are two general responses: add more RAM (allowing the solve to run fully in-core, avoiding the out-of-core penalty entirely) or ensure fast NVMe scratch storage is available (accepting the out-of-core penalty but minimizing its severity). More RAM is generally the better solution when it's a practical option — an in-core solve is faster than even a well-optimized out-of-core solve on the fastest available storage — but RAM capacity has practical and cost limits, particularly on workstation-class (as opposed to server-class) hardware, which is exactly why fast scratch storage remains a relevant, practical consideration for genuinely large simulation problems rather than purely a "buy more RAM and forget about it" situation.
Why This Is Workload-Specific, Unlike General CAD Storage Advice
For CAD-focused workstation use, fast NVMe storage mainly benefits file open/save operations and local PDM/vault cache performance — a real but comparatively modest and occasional benefit. For large-scale FEA/CFD work that regularly runs out-of-core, scratch disk speed can be a continuous, in-the-loop performance factor throughout the entire solve — a meaningfully more significant role than the equivalent storage-speed consideration in CAD-only use, which is why simulation-focused hardware specifications call out scratch disk speed explicitly rather than treating storage as a secondary consideration behind RAM and CPU.
Practical Guidance for Sizing Scratch Storage
For workstations expected to regularly run large simulations that may exceed available RAM, dedicating a separate, fast NVMe drive specifically for solver scratch space (rather than sharing the primary OS/application drive) is common practice — this both provides the fastest available I/O for the scratch workload and avoids scratch-disk activity competing for I/O bandwidth with the operating system and other running applications during a long solve.