Discussion Forum

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

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.

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.

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.

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