|
»Click here to display Table of Contents«
|
Memory Limitations |
|
|
|
|
|
Memory Limitations |
|
|
|
|
|
»Click here to display Table of Contents«
|
Memory Limitations |
|
|
|
|
|
Memory Limitations |
|
|
|
|
On 64-bit machines, when using a 64-bit compiled version of OptiStruct and a 64-bit operating system, OptiStruct can use all memory available in the system (real RAM and virtual memory). There are still some size limitations as a result of the size of standard integer variables, but they should only occur in very rare cases. Currently, OptiStruct is built with two versions of linear solvers: one using 32-bit integers, and the other one using 64-bit integers. By default, the 32-bit solver is used (as it requires less memory/disk and runs visibly faster), but the 64-bit solver is automatically selected when the size of a problem requires it.
OptiStruct can use more memory than is actually installed on a given system (i.e. more than the installed RAM). This is what the virtual memory (swap space) is for. OptiStruct is more efficient, however, if it uses only actual RAM (remember to allow some RAM to be used by the operating system and other codes running at the same time). When more memory is requested than actual available RAM, OptiStruct will run much slower due to swapping. You will hear disks working constantly with little CPU being used, and there will be a significant difference between the elapsed time and the CPU time.
Memory specification for OptiStruct (using –len command line option) is actually only giving OptiStruct a hint about the amount of physical RAM available for the run (i.e. it should specify the amount of physical memory not used by the operating system and other running programs, and as explained above, always less than the total amount of RAM in the computer). Based on this information, OptiStruct will try to use the fastest algorithm which can run within the specified amount of memory. If no such algorithm is available, then the algorithm with minimum memory requirement will be used. Specifying a larger value for –len than the amount of physical RAM may cause excessive swapping during computations, and will significantly slow down the solution process.
On most machines OptiStruct asks operating systems for information about available memory. This information is printed in the header of the .out file, and can be used to issue a warning, when it is possible that the run may fail because of lack of this resource. This information is dynamic (changes with other programs running at the machine) and therefore is never used inside OptiStruct – user supplied information (example: with –len argument or from the config file) is used instead.
In standard modes of operation, OptiStruct automatically estimates the amount of memory required, and this memory is requested in successive steps from the operating system. Sometimes the memory could be used more efficiently if requested at once and not in increments. This can be done using the -fixlen command line option (Run Options). When using the -fixlen option, OptiStruct may start to run, but fail after some time with a memory allocation error. This can happen when almost all available memory is requested by the -fixlen argument, because in addition to the memory required by the OptiStruct solver, OptiStruct launches a bandwidth minimizer, which uses an additional small amount of memory. Requesting slightly less memory with the -fixlen option is a possible solution. Again, you see that it is incorrect to assign too much memory to OptiStruct.
OptiStruct has new command line argument -maxlen which can be used in automatic mode. This switch can be useful in some batch scheduling installations, as it will not allow OptiStruct to use more than a given amount of memory. Note that for models which require more memory than allowed by this argument, OptiStruct will abort during the solution, potentially after spending some time in computations.
OptiStruct has a new command line argument -uselen which can be used in automatic mode. –uselen is used to specify an increased dynamic memory usage limit. If –uselen is not defined, then the algorithms which may use variable amount of memory try to use as minimal an amount as possible. When this option is used, OptiStruct will use more than the minimum memory required, up to this limit, but only when it improves the speed of the solution. This value is used only for some solution sequences, which can profit from additional memory available (for example, to use bigger buffers to store intermediate results).
This value is automatically limited by the value specified by –len, so –uselen can be set safely to a very large value.
(Example: optistruct infile.fem –uselen 32)
Best practices for –uselen specification:
The speed gain is usually modest, and is limited to certain solution sequences, therefore, this run option should not be used unless solution speed is critical and excess memory is available. For single-user hosts, it is useful to set this value to the same as –len (or higher). This maximizes the use of available memory to achieve possible better performance.
Different values of this run option may be used on systems shared by multiple jobs (for example HyperMesh or other solvers). In such scenarios, using a lower value of this run option (or not using it at all), will result in a lower use of memory and may improve overall speed an response time.
All options for memory control can be specified in the OptiStruct Configuration File, however, this is not advisable if the configuration file is shared on the common file server. The configuration files should be tuned for specific hardware independently, and should be placed in the configuration file local to each machine.