One extra comment from me is that I think you and John diagnosed the initial issue correctly, it is that you are using LAPACK for the SCM eigenproblems, and that uses dense matrices. As a result it doesn't scale well to larger problems.
I recall that I set LAPACK as the default for SCM because I had a lot of trouble getting convergence with sparse eigensolvers like SLEPc for this case, I think the SCM eigenproblem is a difficult one to get convergence for. But I think the "real" fix here would be to get SLEPc to converge well, but I think that may not be easy to do (at least I wasn't able to do it reliably when I worked on this originally). Best, David On Tue, Apr 12, 2022 at 10:25 AM John Peterson <jwpeter...@gmail.com> wrote: > > > On Tue, Apr 12, 2022 at 8:47 AM 강다영 <dydy1...@pusan.ac.kr> wrote: > >> Hello, >> Thank you for all your information and suggestions. >> >> You're right that I was using a LAPACK-based solver. >> As you recommended, I first tried to use another solver other than >> LAPACK, and I ended up with a convergence error in SCM. >> >> So second, I performed a mesh convergence study to see if further >> reduction in the DOF (degree of freedom) is possible. >> As a result, I can get a model with a DOF of 36426, far less than the >> maximum DOF available in LAPACK (46340). >> By this, I finally avoided the overflow error. >> >> But the thing is, the new error occurred, and the error message is >> ambiguous this time. >> The exact error message is: >> killed >> > > Depending on your OS, you may be able to figure out exactly why the > process was killed, but my guess is that you are now exceeding the > available memory on your system. For 36426 DOFs, you are trying to > construct a single array of approximately > > echo "36426 * 36426 * 8 / 1024^3" | bc -l > 9.88582876324653625488 > > Gigabytes in size, assuming double precision floating point values. Note > that, even if you have more RAM than this available on your system, it is > possible that there is no "contiguous" chunk of memory of this size > available, which is required when allocating arrays. > > -- > John > _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
