How can I change the allocated memory in CFX and why might I need to do this?

There are various memory settings available, which can be specified from both the solver manager and when running
the solver from the command line. The notes below explain the issues and what to do when certain situations arise.

WHAT IS MEMORY ALLOCATION AND WHY DO PROBLEMS OCCUR?

At the start of a run, the solver estimates the maximum amount of memory likely to be required. Memory is then
requested from the operating system. This estimate is based on parameters such as the mesh size and the physical
models selected. In most cases this estimate is adequate, however sometimes the estimate is wrong and intervention is
required, usually when the solver under-estimates its memory requirements.

HOW TO CHECK THE SOLVER MEMORY ALLOCATION

This is given in the solver output file, visible in the text monitor window in the solver manager. Look for the section
entitled 'Memory Allocated for Run'. Summing the 'Kbytes' values for real and integer memory will give the approximate
memory allocation in kilobytes. If you change any of the memory parameters, it is as well to check that you are getting
what you expect.

SITUATION 1 - NOT ENOUGH MEMORY ALLOCATED

Typically, this situation manifests itself as a failure of the solver with the error messages such as:
'INSUFFICIENT MEMORY ALLOCATED'
'Action required : Increase the integer stack memory size'
'Action required : Increase the real stack memory size'
'CRESLT = FULL'
A solution to this problem is to increase the memory allocation. A sensible first step would be to increase all memory
allocation by a factor of, say 1.2. Setting an individual multiplier for the data type concerned may be useful if memory is
limited.

SITUATION 2 - NOT ENOUGH MEMORY AVAILABLE ON MACHINE

In this case, the solver typically fails with the following messages in the solver output file:
'Run-time memory allocation error'
'Not enough free memoryis currently available on the system'
Here, the solver has attempted to allocate more memory than is available on a machine. It may be useful to check the
solver memory allocation and compare this with the amount of memory available on the machine(s).
Possible solutions are:
- Check that no other memory demanding jobs are running on the machine
- Run the simulation on a machine with more memory
- Run the simulation in parallel on several machines
- Reduce the mesh size
- Use fewer physical models
- If the attempted memory allocation was just a littlemore than the available memory, try reducing the default memory
allocation slightly (e.g. by setting the memory allocation factor to 0.98). Use with care, since reducing the memory
allocation too far will cause the solver to fail with insufficient memory allocated!

SETTING SOLVER MEMORY PARAMETERS

In most cases it is sufficient to set a single memory allocation factor. This affects all data types and is simply a multiplier
of the default memory allocations. For finer control, it is possible to set multipliers or absolute values individually for

each of the data types. This may be specified from the solver manager or via the cfx5solve command. For parallel
simulations, different memory settings may be applied to the partitioner and solver.

SETTING SOLVER MEMORY PARAMETERS VIA THE SOLVER MANAGER

- On the 'Define Run' form, check the 'Show Advanced Controls' tick-box.
- Select either the 'Solver' tab or the 'Partitioner' tab
To set a blanket multiplier for all memory types:
- Set 'Memory Allocation Factor' to the desired value.
To set individual values for each data type:
- Check the 'Detailed Memory Overrides' tick-box.
- Set values for each data type.
Unless the x suffix is used, values are absolute and in words. Suffices M and k denote kilowords and megawords. The x
suffix denotes a multiplier rather than an absolute value.

SETTING SOLVER MEMORY PARAMETERS FROM THE COMMAND LINE

To set a blanket multiplier for all memory types, use:
-size <factor>
For the partitioner ...
-size-part <factor>
To set individual values for each data type, use:
-size-nc
-size-nd
-size-ni
-size-nl
-size-nr
For the partitioner ...
-size-part-nc
-size-part-nd
-size-part-ni
-size-part-nl
-size-part-nr
Again, unless the x suffix is used, values are absolute and in words. Suffices M and k denote kilowords and megawords.
The x suffix denotes a multiplier rather than an absolute value.
As with all of the CFX command line utilities, a full list of the available options for the cfx5solve command may be
obtained by typing: cfx5solve -help

COMMAND LINE EXAMPLES

set a blanket multiplier of 1.2:
cfx5solve -def file1.def -size 1.2
Set a multiplier of 1.5 for integer memory only:

cfx5solve -def file1.def -size-ni 1.5x

Use a real memory allocation of 10 megawords:
cfx5solve -def file1.def -size-nr 10M

MMS CATALOGUE SIZE

This is the maximum number of data areas allowed in the memory management system used in the solver and is
nothing to do with the amount of memory allocated. This issue is dealt with in a separate solution (381455).

Why does the ANSYS CFX-Solver fails during memory allocation on Windows?
The ANSYS CFX-Solver requests its necessary memory from the operating system at the
beginning of the run. If it fails to do so, it will fail with the following error.
+------------------------------------------------------+
*** Run-time memory configuration error ***
Not enough free memory is currently available on the system.
Could not allocate requested memory - exiting!
+------------------------------------------------------+

Windows workstations with large amounts of memory (>2GB) can fail during this stage even
if the total amount of requested memory is less than 2GB. If this happens, first verify that
sufficient Virtual Memory has been allocated in the Operating System. It is recommended
that the maximum size of Virtual Memory be at least twice the size of the available physical
memory.
Even with enough Virtual Memory, the problem may persist and is a limitation of the
Windows Operating System. Under all current 32-bit Windows operating systems (Windows
NT, 2000, XP), the total available address space for any process is 2GB. If the solver is
attempting to allocate more than 2GB of memory, it will fail.
Unfortunately, even if the solver is attempting to allocate less than 2GB of memory, it may
fail. The problem lies in the details of how Windows manages the memory address space
(physical & virtual memory). When a Windows application loads, dynamic link libraries (or
DLLs) may also be loaded at the same time. These libraries are loaded into the memory
address space at the address location specified in the DLL file. Sometimes DLLs will load in
the middle of the address space creating fragmentation of the address space. The
fragmentation reduces the maximum contiguous size of a free block of memory. When the
solver tries to allocate memory, it is given the largest contiguous space in the entire address
range. Depending on where Windows loaded the initial libraries, this may be 1.7GB, 1.3GB,
or even less. You may be surprised to find that a 1.4GB solver run was fine one time, but
failed to allocate memory a subsequent time. This is an unfortunate side effect of how
Windows virtual memory management works.
If the solver fails memory allocation, but is close to the available memory, using explicit
solver memory allocation may allow the case to run. When it starts, the solver estimates the
amount of memory required. Depending of the details of the case, this estimation may be
conservative and request more memory than is actually required (but not by more than about

10%). It is possible to override the solver memory estimate and specify the memory
allocation. For details, see Memory Allocation Factor. Manually decreasing the allocation
may allow the memory to fit within the available contiguous space.
If you have additional parallel keys, another solution is to execute the job with a larger
number of parallel partitions, even if that means having more partitions than number of
CPUs. With more parallel processes, each individual process will be smaller, and at some
point will fit within the process memory limitations. This is done at the expense of some
solver inefficiency due to additional parallel overhead.
Finally, other operating systems such a Linux do not display this limitation and may be
considered if you want to take maximum advantage of your available memory.