For larger simualtion which involves millions of atoms, NAMD will run out of memory especially on node 0. Therefore, this page encourages all discussions on how to reduce memory reduction in NAMD and corresponding implmentations.

There's an initial implementation (I would say a significant engineering on the original NAMD code) which uses less memory. The following gives the instructions how to compile and use this initial memory optimized version.

It requires two steps:

1. Compressing the psf file offline since the memory optimized version only reads a compressed psf file. This function is already integrated into the code. This step should be finished on a local workstation with large memory (say, 1GB).

a) compile your NAMD code

b) add a field "genCompressedPsf on" in the configuration file

c) execute ./namd2 <configuration file> and wait the program to finish

The compressed psf file will now lie in the directory where the original psf file is. The name of the new psf file is simply extended with ".inter"

2. Compile and run the memory optimized version

a) compile the NAMD code adding --with-memopt when you run config to create a build directory

b) modify configuration files:

I. add a field "useCompressedPsf on" in the configuration file, comment the field "genCompressedPsf" if it exists

II. change the "structure" field to use the newly generated psf file by simply adding ".inter"

Besides the above steps, tweaking simulation parameters will enable the running of larger molecule systems (million-atom level) in the clusters that have less memory such as BG/L (512MB on each compute node). The following is a list:

noPatchesOnZero yes

ldbUnloadZero yes

maxSelfPart 1

maxPairPart 1

pairlistMinProcs 128

PMEPencils 1

The maxXPart options reduce the number of compute objects, which should reduce the amount of data the load balancer uses; "pairlistMinProcs" value could be tuned based on memory usage; "PMEPencils" enables the automatic number selection.

For extreme cases we can just postpone load balancing indefinitely:

ldbStrategy other

ldbPeriod 100000000

firstLdbStep 10000000

This isn't as bad as it sounds siince with enough patches the initial distribution.

Another point worth mentioning is that when using this version, the output will be always in the binary format since a large chunk of memory (of size 24*numAtoms Bytes) could be freed. If you specify the text output format, a warning is printed out.

Regarding output trajectory file (DCD file) and restart files, two more parameters could be added to make a run on a small number of processors possible for a very large system (i.e. a million-atom-level system).

noPatchesOnOne yes

ldbUnloadOne yes

noPatchOnOne has very similar meaning with noPatchesOnZero, and it is meaningful only if noPatchesOnZero is enabled. ldbUnloadOne also has very similar meaning with noUnloadZero.

When simulating a million-atom system, the output of trajectory file (DCD file) and restart file will possibly cause insufficient memory on processor 0. If this is the case, setting the newly added parameter "shiftIOToOne" to "yes" can be used to shift those I/O operations to processor 1. It should be cautioned that when this parameter is set, processor 1 could run out of memory if simulating very large system (million-atom system). If this happens, the above two parameters should be set to avoid this problem.