Encyclopaedia Index

Dynamic Memory Allocation


In PHOENICS 3.6 and later versions, the memory management for VR-Editor, EARTH, VR-Viewer, PHOTON/AUTOPLOT and PINTO is handled dynamically.

The previous necessity to recompile and relink in order to have larger arrays therefore has disappeared.

Initial memory allocations are read for each program from the following sections of the CHAM.INI configuration file.

The default copy of this file is in the directory /phoenics/d_allpro. If a local copy exists, the local copy will be used instead.

If the F-array memory allocation specified for the Earth solver is less than 2000000, the solver will make an educated guess at the required F-array dimension, based on the number of variables solved, the number of cells and what models are active.

If more memory is needed than initially allocated, each module will expand the relevant arrays as required. This is done by:

  1. making a temporary copy of the array,
  2. deallocating the original array,
  3. allocating the new, larger array and copying the temporary array into it; and
  4. deallocating the temporary array.

On 32-bit systems, there may come a stage when there is enough available memory to hold the enlarged array, but not enough to hold the temporary copy as well. In that case, the temporary array is written to disc. This introduces a delay in startup, typically around 30s each time the array has to be stretched in this way.

Each time the F-array is stretched, a local copy of CHAM.INI is edited and the current array size is inserted. This ensures that the next time the module is run the right memory allocation is made straight away, eliminating the stretching.

The local CHAM.INI is saved as part of the VR-Editor's ' Save as a case' function, and is restored by ' Open existing case'.

If the grid is very fine, there may not be enough memory to hold the array at all, resulting in a 'memory full' error. This does not relate to the physical ram of the machine, but the limited 32-bit address space being used up. The only solution is to reduce the number of cells being used. This limitation also applies to 32-bit executables running on 64-bit systems.

The file lunit6 contains a history of the memory allocation of an Earth run. The memory allocation history for the Satellite is written to the file lu6pvr. If there appears to be a considerable delay in the start of the calculations, it may be that memory has had to be increased repeatedly. This can be avoided by setting the appropriate entry in CHAM.INI to the value reported in lunit6 or lu6pvr.

64-bit systems do not suffer from this problem, as the address space is for all practical purposes unlimited. Startup of large cases can still sometimes be speeded up by adjusting the Farray size as mentioned above.

In the VR-Editor CHAM.INI can be edited from 'File', 'Open file for editing', 'cham.ini'. The files lunit 6 and lu6pvr can be opened from Windows Explorer in the current working directory.