Following Revisions of GPAW and ASE were used, specify the revisions in install_gpaw_vsc_sl65.sh
:
Notes:
libxc
had to be installed.extra_link_args += ['-lxc']
had to be added.mpicompiler = 'mpiicc'
needed to be set.Following Versions of GPAW and ASE were used:
Following Versions of GPAW and ASE were used:
Following Versions of GPAW and ASE were used:
As other versions, but with special config file:
bash install_gpaw_*.sh all
gpaw-python <DIR_TO_GPAW_INST_BIN>/gpaw-test
For certain problems an assert statement in
~/gpaw_inst_latest/lib64/python2.6/site-packages/gpaw/wavefunctions/lcao.py
has to be commented out (approx line 239):
#assert abs(c_n.imag).max() < 1e-14
#!/bin/sh #$ -N Cl5_4x4x1 #$ -pe mpich 256 #$ -V mpirun -machinefile $TMPDIR/machines -np $NSLOTS gpaw-python static.py --domain=None --band=1 --sl_default=4,4,64
If each of your processes require more than 2GB (and less than 4GB) of memory, you can use the parallel environment mpich8
. This will allocate only 8 processes on each node while still starting 256 processes but distributed over 32 nodes. It is necessary to use the variable $NSLOTS_REDUCED
instead of $NSLOTS
in that case.
#!/bin/sh #$ -N Cl5_4x4x1 #$ -pe mpich8 256 #$ -V mpirun -machinefile $TMPDIR/machines -np $NSLOTS_REDUCED gpaw-python static.py --domain=None --band=1 --sl_default=4,4,64
If even more memory per process is required the environments mpich4
, mpich2
, and mpich1
are also available, as discussed in Hybrid OpenMP/MPI jobs.
Alternatively, you can simply start your GPAW job with more processes which will reduce the amount of memory per process. GPAW usually scales well with the number of processes.
Significant speed up is seen in our test case when –sl_default is set. First two parameters for the BLACS grid should be similar in size to get an optimal memory distribution on the nodes.