I believe many students have encountered the following error when using ANSYS for simulation:
*** ERROR *** ‘There is not enough memory for the Distributed Sparse Matrix Solver to proceed. This error has occurred on the process with MPI Rank ID = 2 on machine (xyz). Please increase the virtual memory on your system and/or increase the work space memory and rerun the solver. The memory currently allocated by this process = 14620 GB. The memory allocation attempted = 7 GB. The largest block of memory allocated by this process that is available for the Distributed Sparse Matrix Solver = 3 GB.’
This error is very frustrating. Sometimes the computer configuration is strong and memory is abundant, yet this message pops up inexplicably. It seems to appear randomly—even without modifying the model, it may crash. Sometimes the model fails at the start, sometimes the second run succeeds miraculously!
Based on Shuige’s experience, even on machines equipped with 128GB memory, normally using only about 100GB, and having successfully solved countless times before, the solver may suddenly report memory errors—the model settings haven’t changed at all.
What exactly is going on?
This article explains the causes and consequences of this error.
First, everyone should understand the MPI mechanism in ANSYS.
For very large models, we generally use multi-core CPU parallel solving. In this case, ANSYS uses MPI to distribute tasks.
An MPI Rank is a solving process, corresponding to a single CPU core. Each Rank is responsible for part of the model and independently manages its own memory. As long as one Rank fails to allocate memory, the entire solution fails completely.
The real reason for the above error is that MPI memory allocation has encountered a problem!
So what situations might cause memory allocation problems? Shuige believes there are generally three main reasons or combinations of different reasons.
Reason 1: Memory Really Is Insufficient
Sometimes, the simplest explanation is correct: the system available memory is indeed insufficient, either physical memory or virtual memory.
After physical memory is exhausted, ANSYS will rely on the system’s virtual memory to temporarily store overflow data. Virtual memory refers to the space reserved on the disk that acts as ‘backup memory’ when physical memory is insufficient. If virtual memory is too small or disabled, the system may crash during memory peaks—even if memory usually seems more than sufficient.
The following phenomena may suggest insufficient memory:
1. The model is very large (millions of degrees of freedom)
2. Memory usage soars to 100%
3. Crashes at the same step every time
Reason 2: Memory Is Sufficient but Fragmented
This is the most common reason. Even if total memory is sufficient, if an MPI Rank cannot find a large enough contiguous memory block, ANSYS will still crash.
Memory fragmentation means that free memory is scattered into many small, non-contiguous areas, making it impossible to allocate larger contiguous blocks—even if total free memory is sufficient.
For example: The system has 6 MB free, but divided into 3 MB, 1 MB, and 2 MB blocks. If the program needs 5 MB, allocation fails—no single block is large enough, even though total free memory is 6 MB.
Like having scattered empty spaces on a bookshelf: The total space is enough for a large book, but the empty spaces are too fragmented and dispersed to fit it.
The following phenomena may suggest this reason:
1. The error message mentions ‘largest block available = X GB’ (as in the error at the beginning of this article)
2. The crash appears random
3. Restarting the computer may temporarily solve the problem
Reason 3: Numerical Instability in the Finite Element Model
This reason is quite common but not easily noticeable, usually stemming from insufficiently constrained or improperly supported components. There are two situations:
1. Insufficiently constrained degrees of freedom will lead to near-singular matrices. Near-singular matrices have stiffness matrices that are almost irreversible, which forces the solver to work harder and significantly increases memory requirements.
2. Components connected only through contact
To deal with instability, ANSYS will perform:
1. Pivoting: Reordering matrix rows/columns to improve numerical stability, which may result in solver pivot warnings;
2. Numerical scaling: Adjusting values to reduce rounding errors and stabilize calculations. These operations significantly increase memory usage—even if memory seems sufficient, errors may be triggered.
For example, the warning everyone often sees is the above situation: ‘Some parts may be held together only by contact. This can lead to rigid body motion or convergence issues. Add proper constraints or enable stabilization damping.’
If numerical instability and memory fragmentation are combined, that’s the worst-case scenario, such as:
1. Random crashes occur
2. Re-running sometimes succeeds
3. Model settings are correct, making it difficult to diagnose specific errors
To facilitate troubleshooting, Shuige has compiled a table of possible causes corresponding to different situations:
Phenomenon vs Possible Cause:
– Crashes at the same step every time: Memory really insufficient or numerical instability
– Memory usage reaches 100% before crash: Memory really insufficient
– ‘Largest block available’ is very small: Fragmentation
– Temporarily normal after restart: Fragmentation
– Random crashes: Fragmentation + numerical instability
– Unconstrained component warning appears: Numerical instability
– Same Rank fails every time: Fragmentation + numerical instability
– Other models also have problems: Memory really insufficient or system-level issues
For different situations, Shuige suggests the following approaches:
Measure vs Why do this:
– Close background programs: Free memory, avoid fragmentation caused by browsers, IDEs, sync tools, etc.
– Check constraints: Ensure model is fully constrained, avoid numerical instability
– Stabilize components connected only by contact: Add weak springs or stabilization damping to prevent kinematic situations
– Restart computer before solving: Clean fragmented memory, reset memory mapping
– Increase virtual memory: Add swap space to handle peaks
– Reduce number of MPI Ranks (use fewer cores while maintaining efficiency): Fewer Ranks = less large contiguous memory needed, reduces fragmentation impact
– Try sparse (non-distributed) solver: Avoid MPI-related memory issues (suitable for debugging)
– Manual mesh partitioning: Balance element count across Ranks, avoid single Rank overload
– Update ANSYS and drivers: Fix known solver/memory bugs or MPI conflicts
– Check if memory modules are faulty: If problems persist, run diagnostic tools
If after performing the above measures the same problem still occurs, it may be that the model itself is very large. In this case, consider optimizing the model, such as increasing mesh size, simplifying the model, reducing result output, etc.
Students with the above confusion might want to give it a try!
For simulation business cooperation, please click: Business Services
For more original courses by Shuige, please click: Shuige’s Original Course List – Up to September 2025
For more finite element learning resources, please visit Shuige’s blog: FSCAE.COM
Best regards,
ANSYS Structural Institute
December 14, 2025
No comments yet