How should I set up the MUMPS solver?

Please login with a confirmed email address before reporting spam

In my solution model, the degree of freedom to be solved is 26032722, and the physical memory of the workstation used is 512G. However, when using the mumps solver, it always utilizes virtual memory, and the usage of virtual memory exceeds the physical memory, even if there is a substantial amount of free physical memory. This greatly slows down the speed of computation. How should this issue be addressed?


5 Replies Last Post 16.02.2025, 02:13 GMT-5
Robert Koslover Certified Consultant

Please login with a confirmed email address before reporting spam

Posted: 1 month ago 13.01.2025, 11:43 GMT-5
Updated: 1 month ago 13.01.2025, 11:43 GMT-5

That is a computationally large model. See: https://www.comsol.com/support/knowledgebase/1030 . Consider using an iterative solver instead of MUMPS.

-------------------
Scientific Applications & Research Associates (SARA) Inc.
www.comsol.com/partners-consultants/certified-consultants/sara
That is a computationally large model. See: https://www.comsol.com/support/knowledgebase/1030 . Consider using an iterative solver instead of MUMPS.

Please login with a confirmed email address before reporting spam

Posted: 1 week ago 15.02.2025, 01:00 GMT-5

First, thank you for your reply. However, for my model, the iterative solver cannot complete the solution, so I have chosen the MUMPS solver.When using the mumps solver, it always utilizes virtual memory, and the usage of virtual memory exceeds the physical memory, even if there is a substantial amount of free physical memory.This problem has bothered me for a long time, and recently it has caused my model to be unable to solve normally.Therefore, I want to know how to set it up to solve this problem. Finally, thank you again for your reply.

First, thank you for your reply. However, for my model, the iterative solver cannot complete the solution, so I have chosen the MUMPS solver.When using the mumps solver, it always utilizes virtual memory, and the usage of virtual memory exceeds the physical memory, even if there is a substantial amount of free physical memory.This problem has bothered me for a long time, and recently it has caused my model to be unable to solve normally.Therefore, I want to know how to set it up to solve this problem. Finally, thank you again for your reply.

Robert Koslover Certified Consultant

Please login with a confirmed email address before reporting spam

Posted: 1 week ago 15.02.2025, 13:22 GMT-5
Updated: 1 week ago 15.02.2025, 14:01 GMT-5

26032722 degrees of freedom is a lot. Note that the shift to virtual memory may be occurring even without first using all the physical memory, when the code seeks to allocate more memory than is physically available. It then has to try to manage the virtual memory in convenient chunks. Have you tried PARDISO instead of MUMPS? Have you tried all the suggestions in https://www.comsol.com/support/knowledgebase/1030 ? Also, if the iterative solver you chose isn't converging, have you tried others? GMRES with the SOR preconditioner normally will converge, but can be very slow. Have you tried improving the mesh quality? Have you tried modifying the geometry (so as to improve the mesh quality or reduce the DoF)? What is your minimum mesh quality, per the report from the mesh statistics? Might you have an ill-posed boundary condition that is causing numerical issues with convergence? Have you carefully checked each and every boundary condition, material setting, port setting, etc? Are you using a user-defined mesh and carefully meshing finely only in places where it is truly necessary? Have you tried using linear discretization instead of the default quadratic discretization? (That can greatly reduce problem size.) Are you taking advantage of any symmetries? Consider posting your .mph file to the forum, to allow others to review it.

-------------------
Scientific Applications & Research Associates (SARA) Inc.
www.comsol.com/partners-consultants/certified-consultants/sara
26032722 degrees of freedom is a lot. Note that the shift to virtual memory may be occurring even without first using all the physical memory, when the code seeks to allocate more memory than is physically available. It then has to try to manage the virtual memory in convenient chunks. Have you tried PARDISO instead of MUMPS? Have you tried all the suggestions in https://www.comsol.com/support/knowledgebase/1030 ? Also, if the iterative solver you chose isn't converging, have you tried others? GMRES with the SOR preconditioner normally will converge, but can be very slow. Have you tried improving the mesh *quality*? Have you tried modifying the geometry (so as to improve the mesh quality or reduce the DoF)? What is your minimum mesh quality, per the report from the mesh statistics? Might you have an ill-posed boundary condition that is causing numerical issues with convergence? Have you carefully checked each and every boundary condition, material setting, port setting, etc? Are you using a user-defined mesh and carefully meshing finely only in places where it is truly necessary? Have you tried using linear discretization instead of the default quadratic discretization? (That can greatly reduce problem size.) Are you taking advantage of any symmetries? Consider posting your .mph file to the forum, to allow others to review it.

Please login with a confirmed email address before reporting spam

Posted: 1 week ago 15.02.2025, 17:24 GMT-5

Robert has a number of excellent suggestions. A general note- if you are using default meshing settings, it is almost certain that careful manual meshing can do better.

If none of this works and you are unwilling to post the model then contacting support might be the only option.

Robert has a number of excellent suggestions. A general note- if you are using default meshing settings, it is almost certain that careful manual meshing can do better. If none of this works and you are unwilling to post the model then contacting support might be the only option.

Please login with a confirmed email address before reporting spam

Posted: 1 week ago 16.02.2025, 02:13 GMT-5

26032722 degrees of freedom is a lot. Note that the shift to virtual memory may be occurring even without first using all the physical memory, when the code seeks to allocate more memory than is physically available. It then has to try to manage the virtual memory in convenient chunks. Have you tried PARDISO instead of MUMPS? Have you tried all the suggestions in https://www.comsol.com/support/knowledgebase/1030 ? Also, if the iterative solver you chose isn't converging, have you tried others? GMRES with the SOR preconditioner normally will converge, but can be very slow. Have you tried improving the mesh quality? Have you tried modifying the geometry (so as to improve the mesh quality or reduce the DoF)? What is your minimum mesh quality, per the report from the mesh statistics? Might you have an ill-posed boundary condition that is causing numerical issues with convergence? Have you carefully checked each and every boundary condition, material setting, port setting, etc? Are you using a user-defined mesh and carefully meshing finely only in places where it is truly necessary? Have you tried using linear discretization instead of the default quadratic discretization? (That can greatly reduce problem size.) Are you taking advantage of any symmetries? Consider posting your .mph file to the forum, to allow others to review it.

OK,thank you,I will have a try

>26032722 degrees of freedom is a lot. Note that the shift to virtual memory may be occurring even without first using all the physical memory, when the code seeks to allocate more memory than is physically available. It then has to try to manage the virtual memory in convenient chunks. Have you tried PARDISO instead of MUMPS? Have you tried all the suggestions in https://www.comsol.com/support/knowledgebase/1030 ? Also, if the iterative solver you chose isn't converging, have you tried others? GMRES with the SOR preconditioner normally will converge, but can be very slow. Have you tried improving the mesh *quality*? Have you tried modifying the geometry (so as to improve the mesh quality or reduce the DoF)? What is your minimum mesh quality, per the report from the mesh statistics? Might you have an ill-posed boundary condition that is causing numerical issues with convergence? Have you carefully checked each and every boundary condition, material setting, port setting, etc? Are you using a user-defined mesh and carefully meshing finely only in places where it is truly necessary? Have you tried using linear discretization instead of the default quadratic discretization? (That can greatly reduce problem size.) Are you taking advantage of any symmetries? Consider posting your .mph file to the forum, to allow others to review it. OK,thank you,I will have a try

Reply

Please read the discussion forum rules before posting.

Please log in to post a reply.

Note that while COMSOL employees may participate in the discussion forum, COMSOL® software users who are on-subscription should submit their questions via the Support Center for a more comprehensive response from the Technical Support team.