Manual Setting of Memory Usage for Feko
Memory is managed dynamically and automatically by Feko. For specific cases, set the memory to be used by Feko.
Feko has the ability to manage memory dynamically, that is the memory required for the geometry data, matrix elements as well as other stages of the solution is determined and allocated at run time. When Feko attempts to allocate memory, in principle the operating system offers a certain address space, which could either be physically installed memory (RAM), but also virtual memory (system swap spaces swapped to the hard disk).
If Feko starts to swap using virtual memory, then the whole solution process can be slowed down quite significantly. Feko also has an out-of-core solution which uses the data on disk in a much more efficient way. (The out-of-core technique is also used, of course, if the problem requires more memory than is available in both RAM and virtual memory.)
For solutions that do not fit into the available RAM, but do fit into the RAM plus virtual memory, the amount RAM to use should be set, less some margin for the operating system.
Two variables, maxalloc and maxallocm were used in older versions of Feko, and for backwards compatibility reasons they are still supported. However, their usage is strongly discouraged.
The variable maxallocm sets the maximum memory in MBytes that can be allocated together by all Feko processes launched as part of one parallel Feko job per host.
For example, the definition maxallocm = 400
will allow a maximum of 400
MByte of memory to be allocated on every host. If there are two hosts then the maximum
memory over all processes and hosts that can be used would be 800 MByte. If this is
insufficient, the matrix will be saved to the hard disk (if an out-of-core solution is
feasible) or Feko will halt with an error message. For
parallel versions of Feko the memory limit will apply for
each process and is determined by dividing the value of maxallocm by
the number of parallel processes on the same host.
In newer Feko versions (for both Windows and Linux) the memory management is fully automatic and the usage of virtual memory (swap space) is avoided as far as possible. On UNIX versions an environment variable FEKO_MAXALLOCM may be defined during the installation and set up internally by means of Lua initialisation scripts. The environment variable FEKO_MAXALLOCM specifies the physically installed RAM less an operating system reserve for a specific machine. The advantage then is that the models are machine independent - with two different computers with different memory, no variable maxallocm has to be changed in the model. Therefore the memory management is either fully automatic (Windows or Linux) or defined on a per machine basis (other UNIX versions).