libMesh / libmesh

libMesh github repository
http://libmesh.github.io
GNU Lesser General Public License v2.1
634 stars 284 forks source link

Argument out of range #3411

Open ehsanakrami opened 1 year ago

ehsanakrami commented 1 year ago

Hello,

I have a problem with the Sparsity Pattern. I want to simulate a multiphysics problem. At first, I defined a Fluid and a Solid system with 4 and 3 variables, respectively. The multiphysics system is FSI with 7 variables. I need to assemble the Fluid and the Solid system individually and transfer their Matrices and RHS into the FSI system according to the DoF of variables and their peers in the FSI system.

At the first nonlinear iteration, everything looks normal, and the Fluid and solid system are correctly assembled into the FSI system, and the results of the first step of nonlinear are identical to the decoupled Fluid and Solid solution. But in the second nonlinear iteration, there is an "Argument out of range, New nonzero at (1242,1312) caused a malloc" happened.

I know that the Matrix of the system is spare, and there is a pre-allocation according to the estimated sparsity pattern, but the FSI algorithm did not ask to access an out-of-range memory. During the nonlinear iteration, DoF and sparsity patterns are not changed. I wonder why it is working correctly at the first nonlinear iteration and facing this error at the second nonlinear iteration while everything is the same.

It would be greatly appreciated if somebody could help me with this issue.

roystgnr commented 1 year ago

the FSI algorithm did not ask to access an out-of-range memory

Maybe not directly, but if it asks to assemble into a sparse matrix entry that wasn't preallocated, then it will be asking for that access indirectly.

The details of how that happened depend completely on your algorithm; e.g. an ALE algorithm will usually be safe because changes in geometry (until remeshing is needed) don't lead to changes in mesh topology, whereas in an algorithm with a solid mesh overlapping a fluid mesh it's easy for the overlap to change (which thereby changes which DoFs are coupled to which other DoFs) as the solid mesh is moved.

If your sparsity pattern might be changing from nonlinear iteration to nonlinear iteration, then you're going to need to make sure that the sparsity pattern which gets preallocated is the union of the possible sparsity patterns you might encounter during the nonlinear convergence. The best way to do this might be to add a custom GhostingFunctor subclass as a coupling functor in your DofMap.

ehsanakrami commented 1 year ago

Thank you for your response. The sparsity is not changed, and there is no mesh movement in the first times-step loop (consisting of the nonlinear loop). Identical matrix assembling leads to an out-of-range error. I can send you the code to have a quick look in to it.