Does out-of-core solving produce less accurate results than an in-core solve?

No — out-of-core solving is a performance/memory-management technique, not an approximation method. It produces the same numerical result as an in-core solve of the identical problem; the only difference is solve time, which is typically longer for an out-of-core solve due to the additional disk I/O overhead.

How much scratch disk space should be allocated for a large simulation?

This varies significantly by problem size and solver, but scratch space requirements can be a substantial multiple of the model's core memory footprint for very large problems — checking the specific solver's documentation for scratch-space sizing guidance relative to expected problem DOF, or monitoring actual scratch disk usage during a representative test run, is more reliable than a generic rule of thumb.

Is it worth buying a dedicated scratch drive if I only occasionally run large out-of-core solves?

For occasional large solves, sharing fast NVMe storage between the OS/applications and scratch use is a reasonable compromise — a dedicated scratch drive provides the most benefit for workstations that regularly and routinely run large simulations, where the performance gain justifies the added hardware cost and complexity of a separate dedicated drive.

Engineering·6 min read·August 14, 2026

💿 Why Scratch Disk I/O Speed Matters for Large FEA/CFD Solves

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.

By EngineersUniverse Editorial Team

Engineering Editorial & Technical Review Team

Published August 14, 2026

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.

Topics covered

scratch disk FEAout of core solversimulation storage bottleneckNVMe SSD simulation performance