Problem Description

Handling memory intensive models

Solution

Introduction

On 32-bit platforms there is a theoretical upper limit of addressable memory (physical RAM + disk swap space). When a model hits the upper limit during during the solution progress, an error message "Out of memory" may appear. We recommend the use of a 64-bit platform to anybody working with sizable models. With this architecture there is virtually no theoretical address limit. If you get too large models you will instead notice it by a marked slow-down when the physical RAM is exhausted and the swap space is used. Disk swapping can be painfully slow. Below is a guided tour on how you can make your large models more economical—thereby saving computational time. If you are limited to a 32-bit platform you can get some software settings tips in Knowledge Base solution 1030.

Run client-server mode

If you have access to a dedicated computation server with lots of RAM, a good option is to run the COMSOL user interface on your desktop computer and run the computations on the dedicated server. To run a COMSOL Multiphysics server and a COMSOL Multiphysics client on different computers, you need a floating network license.

Building memory efficient models in COMSOL Multiphysics

It is a delicate task to give a general rule how much memory is needed for a specific problem. It depends on

Number of nodes in the geometry mesh (base mesh).
Type of shape function, (for example 2nd order Lagrange elements). The shape function type together with the geometry mesh determines the size of computational mesh (extended mesh).
Number of dependent and independent variables.
Sparsity of system matrices. Sparsity can be affected by the degree of coupling between different equations. The shape of the geometry and mesh also has impact on matrix sparsity: A thin or flat object with a large fraction of the degrees of freedom on the surface tends to be make sparser systems than a compact and bulky object like a sphere or a cube.

From the last item above we understand that the amount of memory required to solve a problem depends on the number of non-zero entries in the Jacobian matrix, not the number of degrees of freedom. For example, for a non-isothermal flow problem coupled to the conduction-convection equation and ideal gas law equation of state, all 5 dependent variables (u, v, w, p, T) appear in all 5 equations (in 3D). Hence the Jacobian matrix will be much fuller than a simple heat conduction problem. This is also the reason why solving a thermal radiation problems often uses up a lot of memory. The contribution to the Jacobian matrix from any surface elements creates a block in the matrix which is full.

Read more about the definition of Degrees of Freedom (DOF) in COMSOL Multiphysics.

Postprocessing

If you run out of memory during postprocessing, you can increase the maximum Java heap size. On Windows, modify the file COMSOL34/bin/comsol.opts and on Sun/Linux/Mac OSX, modify the file COMSOL34/bin/comsol. Increase the value of parameter MAXHEAP=256m from 256MB to a higher value, say 512, by changing to MAXHEAP=512m.

Selecting Proper Solver Type

The solvers in COMSOL Multiphysics always break down each problem into the solution of one or several linear systems of equations. Thus, in all the solvers the choice between direct and iterative solvers for linear systems affects the solution time and memory requirements.

The direct solvers solve a linear system by Gaussian elimination. This stable and reliable process is well suited even for ill-conditioned systems. These solvers require less tuning and are often faster than the iterative solvers in 1D and 2D, where they are the default setting. The elimination process sometimes requires large memory resources and long computing times, an effect particularly noticeable for 3D models.

COMSOL Multiphysics 3.4 supports automatic detection for symmetric matrices system; by default the option "Automatic" is selected. However, if your linear solver does not take advantage of symmetry, such as UMFPACK, you won't see any improvement. (Note: Symmetric in this case does not mean a symmetric geometry. Rather, it refers to the Jacobian matrix being symmetric along the diagonal, see further the COMSOL Multiphysics User's Guide, section Solving the Model).

The default setting for 3D calls on iterative solvers. They generally use less memory than direct solvers and are often faster in 3D. For optimal performance, though, the iterative solvers need the careful selection of a preconditioner. Some examples of preconditioners are

Geometric Multigrid
Algebraic Multigrid
SSOR Vector
Incomplete LU
et.c.

For large problems, it is imperative to choose a preconditioner that is suitable for the problem type at hand. Please refer to the COMSOL Multiphysics User's guide, section The Linear System Solver for more information.

COMSOL Multiphysics 3.4 includes a segregated solver that allows you to control the solution process to reduce memory consumption. This solver is particularly efficient for weakly coupled multiphysics problems, because the different physics types can then be solved separately without convergence issues. Typically, the price you need to pay is more iterations than the ordinary nonlinear solver.

Efficient Geometry Modeling

In general, the first step is to try to reduce the model geometry as much as possible. Often you can find symmetry planes and therefore reduce the model to 1/2 or 1/4 or even 1/8 of the original size. The memory usage does not scale linearly, rather polynomially (A*n^k, k>1), where A is a constant, n the number of degrees of freedom, and k a real number describing the polynomial order. The value of k may vary depending on the geometry dimension (1D, 2D, or 3D) and solver settings, but is always greater than one. This means that you save more than half the memory if you find a symmetry plane and cut the geometry size by half. Note that symmetry should be for both the geometry and the physics.

Avoid small geometry objects where they are not needed (for curved segments, use one Bézier-curve instead many small line segments, for example)
Try using Draw>Use assembly and "interactive meshing" to generate the mesh. This will give you more flexibility as the nodes in elements in adjacent subdomains need not be matched. This allows for less number of elements.
Also, the quality of the mesh is important if an iterative solver is used. Convergence will be faster and more robust if the element quality is high. If an angle in a mesh element corner approaches 180 degrees, the quality will be too low. This is often the case for triangular or tetrahedron elements in thin layer regions. Quad and hexahedron elements can also have low quality in some cases. If you select Mesh>Mesh Statistics, you will see the Minimum element quality. It should not be lower than 0.01.

A note on virtual memory on 64-bit Windows Vista

If the solvers run out of physical RAM, the virtual memory will kick in and the hard disk will be used for intemediate storage of memory data. On 64-bit Vista the computer may become unresponsive during this process. Not even the task manager is reachable before the model is solved. One way to circumvent this deadlock is to use a USB flash memory - together with Readyboost.

CAFE

Support Knowledge Base

[830-2]Handling memory intensive models