Hyper-Threading problem?

Vasp transition state theory tools

Moderator: moderators

Post Reply
barryhyc
Posts: 12
Joined: Mon Jan 12, 2009 7:41 am

Hyper-Threading problem?

Post by barryhyc »

Hi, everyone. I met some questions about the compilation of vasp5.2 with the code of VTST2.04b. The executable file of vasp can be obtained. But in practical computation process, two problems make me confused.
(1) The parameter "NPAR" must be set in INCAR. Otherwise, the energy is positive and the structure cannot be converged.
(2) If NPAR is not added in INCAR, the crystal computational task can be conducted correctly, but the slab model cannot be converged. Strangely, the DIV or ALGO=38 method cannot be executed unless NPAR tag is set.
Now, we always add NPAR in INCAR. But the efficiency is worse than 4.6 version. Also I don't know the appropiate value of NPAR. (Our machine takes dual quad-core architecture. )
Today I submit a NEB task. The NPAR has been set in INCAR, still the energy is positive. So how can I solve these problems? Is hyper-threading problem or some compilation options incorrect?
Many thanks!
barryhyc
Posts: 12
Joined: Mon Jan 12, 2009 7:41 am

Re: Hyper-Threading problem?

Post by barryhyc »

Maybe I don't clearly describe the problems what I encounter.
The questions are, for example, when I submit a task of slab model (NiM alloy), if NPAR tag was not set in INCAR (
ISMEAR= 1
SIGMA=0.20 #need to test
GGA=PE #need to test
ISIF = 2
IALGO=48
ENMAX= 400
NSW=500
IBRION=2
VOSKOWN=1
IDIPOL=3
VOSKOWN=1
ENAUG=650
LREAL=Auto
LMAXPAW=0
LPLANE=.TRUE.
LCHARG=.FALSE.),
the out file export the warning message as "
For optimal performance we recommend that you set |
| NPAR = approx SQRT( number of cores) |
| This will greatly improve the performance of VASP for DFT. |
| The default NPAR=number of cores might be grossly inefficient |
| on modern multi-core architectures or massively parallel machines. |
| Unfortunately you need to use the default for hybrid, GW and RPA |
| calculations. "
Meanwhile, the energy is always positive and donnot converge within the 60 electronic steps (out file: partial
N E dE d eps ncg rms rms(c)
RMM: 1 0.445544783814E+04 0.44554E+04 -0.11071E+05 1080 0.110E+03
RMM: 2 0.223476121357E+04 -0.22207E+04 -0.22561E+04 1080 0.259E+02
RMM: 3 0.166365682294E+04 -0.57110E+03 -0.61044E+03 1080 0.965E+01
RMM: 4 0.152723672960E+04 -0.13642E+03 -0.15017E+03 1080 0.554E+01
~)
. When NPAR=2 or 4 (I donnot know the optimized value for our machine, dual quad-core architecture) was added in INCAR, the calculation is normal. But the effeciency is worse than that vasp4.6.

Recently, I submit a NEB calculation. Although the NPAR parameter is set in INCAR, the energy is always positive. The makefile is attached, please have a look. Also, when I type the command "top" at the terminal, the status of vasp always display many "S" not "R" (i. e., 6S and 2R in 8 CPUs). So could you tell me what is wrong with our vasp compilation process? Or the hyper-threading problem?

Thanks.
Attachments
makefile.txt
(15.55 KiB) Downloaded 8836 times
graeme
Site Admin
Posts: 2291
Joined: Tue Apr 26, 2005 4:25 am
Contact:

Re: Hyper-Threading problem?

Post by graeme »

I don't see how this is related to the vtst code. If you see the same problem doing a regular vasp calculation, it is likely a problem with compilation (e.g. the math library).

We have seen poor performance using hyperthreading, but not a problem with the calculation results.

If there is any evidence that the problem is directly related to our code, please let us know.
Post Reply