Memory Handling

OptiStruct, as of version 2020, is primarily packaged with completely 64-bit modules (64-bit integer, 64-bit floating point), except for some single precision (64-bit integer, 32-bit floating point) modules.

OptiStruct, as of version 2020, is primarily packaged with completely 64-bit modules (64-bit integer 64-bit floating point); except for some single precision (64-bit Integer 32-bit floating point) modules. Single precision modules, if required, can be selected via the -sp run option.

Starting from OptiStruct 2021.1, for the various memory run option settings (-fixlen, -maxlen, -len, and so on) for MPI runs, the default interpretation is that the specified values are for each host. For previous versions, the default was that the values were input per MPI process. This is controlled using the -hostmem yes/no run options or SYSSETTING,HOSTMEM,YES/NO options.

OptiStruct can use more memory than is actually installed on a given system (that is, 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, due to CPU wait for disk access.

It is recommended that every run of OptiStruct should use the -len option to indicate how much memory OptiStruct can use. OptiStruct will run correctly without this argument (it will assume a default value of 8000 = 8 GB RAM), but then it may run less efficiently than if it was allowed to run with more memory.

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 (that is, 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.

In addition to the -len option described above, the following options can be used to control how OptiStruct allocates memory:

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. Command line arguments -minlen can be used in automatic mode to reduce the successive steps by providing more memory from the beginning. Sometimes the memory could be used more efficiently, if requested at once and not in through frequent increments. Sometimes -minlen with a high amount of requested memory may not leave enough space for some other processes (refer to -fixlen below).

Typically most equation solvers (for instance, MUMPS) in OptiStruct only have two memory core modes, that is in-core and out-core modes. In the case of BCS solver, all three memory modes are available (in-core, out-core, and min-core). Generally, you would only need to either use in-core or out-core modes for the vast majority of models. For a particular model, run a check run (-check) and if the recommended memory is available, then use in-core mode, otherwise, use out-core mode.

One additional memory control is the fixed mode option -fixlen, in which memory is allocated only once and resizing is prohibited. 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. MUMPS sparse solver also allocates memory directly from operating system. In the case of a lot of memory assigned by -fixlen, MUMPS solver may have no memory resource to use or has to use virtual memory with extreme low efficiency. It can practically happen in terms of domain decomposition run with many processes, in which -fixlen refers to memory for each MPI process.

In general, automatic memory mode is recommended in all cases.

All options for memory control can be specified in the 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.