Introduction

*** 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.”

If you’ve used ANSYS Mechanical for large simulations, this error probably looks familiar — and frustrating. Despite running a powerful machine with plenty of RAM, you may get this message unexpectedly. It often shows up randomly, without any change to the model. Sometimes it crashes early. Other times it solves completely on a second try.

Based on my experience, even on a system with 256 GB of RAM, where the model typically uses only around 150 GB and has successfully solved many times before, the solver can still crash unexpectedly with a memory error—despite no apparent changes to the model setup. Why does this happen?

This guide explains:

• ✅ What this message really means
• ✅ The 3 most common causes
• ✅ How to troubleshoot and address it efficiently

MPI, Ranks, and Memory — A Quick Primer

When you solve a model in parallel using multiple CPU cores, ANSYS uses MPI (Message Passing Interface) to divide the task.

📘 MPI Rank
An MPI rank is a solver process mapped to a single CPU core. Each rank handles part of the model and manages its own memory. If even one rank fails to allocate memory, the entire solution fails.

So What Causes This Error?

Now that we’ve briefly touched on how memory is divided across MPI ranks, let’s explore the real reasons this error appears — even on high-memory systems. In most cases, it boils down to one or more of three key causes.

1. You’re Genuinely Out of RAM

Sometimes, the simplest explanation is the correct one: your system may not have enough usable memory, either in the form of physical RAM or virtual memory (Page File).

Clues:

• Large model (millions of DOFs)
• RAM usage spikes to 100%
• Crash occurs at the same point every time

When physical RAM is exhausted, ANSYS relies on your system’s virtual memory (also called the page file) to temporarily hold overflow data.

📘 Virtual Memory / Page file
A reserved portion of disk space that acts like backup RAM when physical memory runs out. If the page file is too small or disabled, the system may crash during memory spikes — even if total RAM is normally sufficient.

2. You Have Enough RAM — But It’s Fragmented

This is a frequent culprit. Even if your system has ample RAM, ANSYS may crash if a single MPI rank cannot find a large enough continuous memory block.

Clues:

• Error message reports “largest block available = X GB” (as in the error message quoted above)
• The crash seems random
• Rebooting temporarily fixes the issue

📘 Memory Fragmentation
Memory fragmentation occurs when free system memory is scattered into small, non-contiguous blocks, hindering the allocation of larger contiguous chunks even if enough total memory is available.

For example, Your system has 6 MB free, but split into 3 MB, 1 MB, and 2 MB blocks. If a program requests 5 MB, it fails—no single block is big enough, even though 6 MB is free.

This is like a bookshelf with scattered gaps: You have enough total space, but a large book won’t fit if the free slots are small and separated.

3. The Model Is Numerically Unstable

A very common but less obvious cause is numerical instability, often due to under-constrained or poorly supported parts.

Causes:

• Unconstrained degrees of freedom (DOFs) resulting in a Nearly Singular Matrix
  
  📘 Nearly Singular Matrix
  The stiffness matrix is almost non-invertible, often due to too much flexibility or missing restraints. This forces the solver to work harder, increasing memory demand.
  
• Parts connected only by contact

To deal with instability, ANSYS performs:

• 📘 Pivoting: Reordering matrix rows/columns to improve numerical stability (You may get solver pivot warnings)
• 📘 Numerical Scaling: Adjusting values to reduce rounding errors and stabilize computation

These actions increase memory usage significantly — which may trigger the error even when RAM seems sufficient.

🔔 ANSYS may show warnings like:
“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.”

4. Instability + Fragmentation = Worst Case

When numerical instability causes a spike in memory need — and fragmentation prevents that memory from being available — you get the worst-case scenario:

• Crashes appear random
• Re-runs sometimes succeed
• The error is difficult to diagnose

Diagnosing the Cause

Symptom	Likely Root Cause
Crashes consistently at same step	🟥 Out of RAM or 🟩 Numerical Instability
RAM usage hits 100% before crash	🟥 Out of RAM
“Largest block available” is small	🟦 Fragmentation
Works after reboot	🟦 Fragmentation
Crashes randomly	🟪 Fragmentation + Numerical Instability
Warning about unconstrained parts	🟩 Numerical Instability
Same rank fails every time	🟪 Fragmentation + Numerical Instability
Other models fail too	🟥 Out of RAM or System-level issue

What You Can Do

✔️ Action	💡 Why It Helps
Close background apps	Frees up RAM and avoids fragmentation from browsers, IDEs, sync clients, etc.
Verify constraints	Ensures model isn’t under-constrained; prevents numerical instability
Stabilize contact-only parts	Add weak springs or stabilization to prevent floating bodies
Reboot before solving	Clears fragmented RAM and resets memory map
Increase virtual memory (admin privileges req.)	Increases available swap space to handle spikes
Reduce MPI ranks (Solve on fewer CPU Cores)	Fewer ranks = fewer memory blocks needed, reducing fragmentation
Try sparse (non-distributed) solver	Avoids MPI-related memory issues (useful for debugging)
Use manual mesh partitioning📘	Balances element count across ranks; avoids overload on one rank
Update ANSYS and drivers	Fixes known solver/memory bugs or MPI conflicts
Check for faulty RAM	Run diagnostics if issues persist across models or after reboot

📘By default, ANSYS automatically divides the mesh across MPI ranks using heuristics. However, this can sometimes result in one rank receiving a disproportionately large number of elements — especially in irregular or asymmetric models. This can cause that rank to run out of memory while others remain underutilized. Manual mesh partitioning lets you assign or influence how the mesh is split across ranks, ensuring a more balanced workload and preventing memory overload on a single process. This can help avoid crashes triggered by rank-specific memory issues.

Final Thoughts

The “not enough memory” error doesn’t always mean you’re truly out of RAM. It’s often a blend of:

• Fragmented memory
• Poor constraints
• Contact-only parts
• Or, yes — real memory limits

Start with the quick fixes: close background apps, check your constraints, and reboot. Then, if needed, explore deeper tweaks like adjusting ranks or partitioning. With a structured approach, you can often eliminate the error without altering your model at all.

🧠When running FEA, it’s not just about how much memory you have — it’s how well it’s managed.

Good Luck!

Want to Go Deeper?

If you’re serious about mastering simulation workflows in ANSYS, check out our eBook:

All Models Are Wrong: Structural Analysis with Ansys Workbench (Third Edition) available for $12.50.

It’s a practical, example-driven guide that goes beyond theory — covering real-world modeling decisions, convergence issues, boundary condition tricks, and validation techniques.

Check out the free preview : All Models are Wrong