Issue Running IBAMR on Supercomputer: "No available patch data component indices left" Error

38 views
Skip to first unread message

LIMING CHAO

unread,
May 2, 2025, 8:40:49 AMMay 2
to IBAMR Users
Dear all,

I am encountering an issue when running an IBAMR simulation on a supercomputing platform. The same simulation case runs without any problems on my local machine, but it fails on the supercomputer with the following error message:  

At beginning of timestep #52  
Simulation time is 0.0052  
IBHierarchyIntegrator::advanceHierarchy(): time interval = [0.0052, 0.0053], dt = 0.0001  
IBHierarchyIntegrator::preprocessIntegrateHierarchy(): performing Lagrangian forward Euler step  
IBHierarchyIntegrator::advanceHierarchy(): integrating hierarchy  
IBHierarchyIntegrator::integrateHierarchy(): computing Lagrangian force  
IBHierarchyIntegrator::integrateHierarchy(): spreading Lagrangian force to the Eulerian grid  
IBHierarchyIntegrator::integrateHierarchy(): solving the incompressible Navier-Stokes equations  
P=00000: Program abort called in file ``/data/home/chaoliming92/IBAMR/sfw/samrai/2.4.4/linux-g++-opt/include/PatchDescriptor.C'' at line 77  
P=00000: ERROR MESSAGE:  
P=00000: PatchDescriptor::definePatchDataComponent error...  
P=00000: No available patch data component indices left.  
P=00000: Application must be restarted and size must be increased.  
P=00000: See tbox::SAMRAIManager utility for more information.

Could you kindly advise what might be causing this issue, and how I might resolve it? I would appreciate any guidance on whether this is related to memory allocation limits, SAMRAI configuration, or differences between the local and cluster environments.

Thank you in advance for your support.

Best,

Li-Ming

Boyce Griffith

unread,
May 2, 2025, 9:21:59 AMMay 2
to IBAMR Users
This kind of error usually means that the iterative linear solver stagnated and failed to converge. This can happen if you have overlapping patches, which the SAMRAI AMR grid generator sometimes will produce. The generated patches also can be different when you run on different numbers of processors. What are your gridding algorithm settings?

--
You received this message because you are subscribed to the Google Groups "IBAMR Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibamr-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ibamr-users/498c0f4a-61f1-41bc-8b9a-4836b896dd12n%40googlegroups.com.

LIMING CHAO

unread,
May 2, 2025, 10:06:36 AMMay 2
to IBAMR Users
Dear Prof.Boyce,

Thank you very much for your reply. Currently, I am using a vorticity-based adaptive mesh refinement (AMR) for my grid.

A friend of mine suggested that the issue might be due to a missing SAMRAI setting in my example.cpp file. I also came across a related post in the user group:
https://groups.google.com/u/0/g/ibamr-users/c/AXIRppCANIk/m/GYFaNyGcAwAJ
which mentions that we need to set:
SAMRAIManager::setMaxNumberPatchDataEntries(2048);
before calling SAMRAIManager::startup().

I am currently trying this solution.

Best,

Li-Ming

Boyce Griffith

unread,
Jun 4, 2025, 6:32:53 PMJun 4
to IBAMR Users

On May 2, 2025, at 10:06 AM, LIMING CHAO <chaoli...@gmail.com> wrote:

Dear Prof.Boyce,

Thank you very much for your reply. Currently, I am using a vorticity-based adaptive mesh refinement (AMR) for my grid.

A friend of mine suggested that the issue might be due to a missing SAMRAI setting in my example.cpp file. I also came across a related post in the user group:
https://groups.google.com/u/0/g/ibamr-users/c/AXIRppCANIk/m/GYFaNyGcAwAJ
which mentions that we need to set:
SAMRAIManager::setMaxNumberPatchDataEntries(2048);
before calling SAMRAIManager::startup().

I am currently trying this solution.

It could be, but if everything is working correctly, the iterative solvers should take <= 10 iterations, and so you should not need to increase the number of patch data indices that are allocated…

You can get some information about why the linear solvers are converging (or not) by including some command-line flags: -stokes_ksp_monitor -stokes_ksp_converged_reason

If there is a big jump in the iteration count, then that is a clue that something has gone wrong in the AMR grid set up.

— Boyce

Reply all
Reply to author
Forward
0 new messages