Vasp parallel version does not use more than 55% cpu
Moderators: Global Moderator, Moderator
Vasp parallel version does not use more than 55% cpu
I have implimented vasp 4.6.21 on 3 machines using ROCKS , intel 8 compiles and mpich 1.2.5. It works fine but it doesn't use more 55% cpu. what can be done to make it more optimized?
Last edited by Vihang on Tue Dec 21, 2004 4:24 am, edited 1 time in total.
-
- Administrator
- Posts: 2921
- Joined: Tue Aug 03, 2004 8:18 am
- License Nr.: 458
Vasp parallel version does not use more than 55% cpu
in principle, the paralellisation behavior can be set by
the following parameters in INCAR:
NPAR, LPLANE (please have a look to the online manual,
http://cms.mpi.univie.ac.at/CMSPage/main
chapter parallelisation.
However, the reasons for your problems may also be one of the following:
1) LINUX drivers for the Gigabit card are not optimized (or the wrong
switches are set, when loading the modules in modules.conf).
Admittedly I have no clue what to set (we buy from init.at, and they do
everything to optimised the drivers).
2) Bad switches. We have HP switches with hard ware collision dedection enabled
(what ever that means, again this lies in the responsability of our hardware
supplier init.at).
Roughly:
the switches force the Gigabit cards to slow down, when they can
not cope with the traffic. If this option is not enabled performance of VASP can slow down by 100-200 % on 8 nodes.
3) Unlikely but possible: bad linux kernel (unlikely since any reasonably new kernel is fine).
For some further information, please also check the last
section of the FAQs of the VASP-online manual
the following parameters in INCAR:
NPAR, LPLANE (please have a look to the online manual,
http://cms.mpi.univie.ac.at/CMSPage/main
chapter parallelisation.
However, the reasons for your problems may also be one of the following:
1) LINUX drivers for the Gigabit card are not optimized (or the wrong
switches are set, when loading the modules in modules.conf).
Admittedly I have no clue what to set (we buy from init.at, and they do
everything to optimised the drivers).
2) Bad switches. We have HP switches with hard ware collision dedection enabled
(what ever that means, again this lies in the responsability of our hardware
supplier init.at).
Roughly:
the switches force the Gigabit cards to slow down, when they can
not cope with the traffic. If this option is not enabled performance of VASP can slow down by 100-200 % on 8 nodes.
3) Unlikely but possible: bad linux kernel (unlikely since any reasonably new kernel is fine).
For some further information, please also check the last
section of the FAQs of the VASP-online manual
Last edited by admin on Fri Apr 22, 2005 12:40 pm, edited 1 time in total.