2,652
edits
Problems: Difference between revisions
→huge frames leading to overflow of the shell's stack limit: exceeding the 4GB barrier when using the 32bit binary
(→huge frames leading to overflow of the shell's stack limit: exceeding the 4GB barrier when using the 32bit binary) |
|||
| Line 15: | Line 15: | ||
The numbers above mean a 10-fold increase over the default, and should be enough. I've found this to be necessary for unusually large frames (32 MB). | The numbers above mean a 10-fold increase over the default, and should be enough. I've found this to be necessary for unusually large frames (32 MB). | ||
xds_par in this case also might need an increase of the environment variable OMP_STACKSIZE (e.g. "setenv OMP_STACKSIZE 128M"). | xds_par in this case also might need an increase of the environment variable OMP_STACKSIZE (e.g. "setenv OMP_STACKSIZE 128M"). | ||
=== memory consumption exceeding the 4GB barrier when using the 32bit binary === | |||
As pointed out by James Holton, the memory consumed by huge frames in combination with many threads may be larger than 32 bits allow. Execution then stops with | |||
forrtl: severe (41): insufficient virtual memory | |||
The workaround is to limit the [http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html MAXIMUM_NUMBER_OF_PROCESSORS], or to use XDS instead of XDS_PAR. An even better solution is to switch to the 64bit binary, but that of course requires a 64bit operating system. | |||
=== Problems with OpenMP === | === Problems with OpenMP === | ||