[Pw_forum] ph.x v3.2 on NEC SX-8
akohlmey at cmm.chem.upenn.edu
Fri Dec 29 00:49:29 CET 2006
On 12/28/06, wlyim at puccini.che.pitt.edu <wlyim at puccini.che.pitt.edu> wrote:
> Thanks for your suggestion. I will try one of the examples as soon as
> Current status: ifort-compiled pw.x and ph.x can complete the job
> normally. However, the NEC executables pass a larger "nrxx" value, 22200
> in NEC vs 20736 in Intel, given that nr1=24,nr2=24,nr3=36. So in NEC, some
that is very interesting.
> zero "zeta" were passed to dmxc_spin subroutine which led to "divide by
> zero" error at line 1192 in Modules/functionals.f90. Interestingly, pw.x
> by sxcross compiler and ifort gave the same scf results, while ph.x in NEC
> didn't work...
no surprise here. pw.x does not need the derivatives of the exchange-
> Any suggestion is welcome, e.g. compiler options, preprocessor flags...
from looking at the code it seems that the relation nrxx=nrx1*nrx2*nrx3 is
only true in the serial case. see Modules/fft_types.f90 lines 242ff.
the intel compiler code usually continues with a denormalized number
(NaN or Inf) after a division by zero (same as IBM xlf) and since the
corresponding grid point is not accessed this does not propagate.
to remedy the situation you can try a) compile a serial version of the code,
b) look for a compiler flag to continue after a denormalized number, or
c) correct the code in PH/phq_setup.f90 to call dmxc()/dmxc_spin()
only for values or 'ir' that correspond to valid grid points.
> Best regards,
Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu
Center for Molecular Modeling -- University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
If you make something idiot-proof, the universe creates a better idiot.
More information about the users