[Wien] SCF crash, XLF IBM

Fri Mar 15 17:27:38 CET 2013

Dear WIEN2k community,

   I am trying to use WIEN2k 12.1 in the "Spanish Supercomputing Network"
(RES), more specifically, the TIRANT machine at Valencia University
(PowerPC processors and XLF compiler). The guys from RES had a hard work to
compile WIEN2k (I believe mainly due to XLF) and now, we are facing a
problem when trying to calculate a simple example, namely, InP in the zinc
blend phase in sequential mode.
   The initialization goes fine, but when I start the SCF cycle, I get:

STOP  LAPW0 END
STOP  LAPW1 END
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '.' in the input file.  The program will
recover by assuming a zero in its place.
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit 'E' in the input file.  The program will
recover by assuming a zero in its place.
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '-' in the input file.  The program will
recover by assuming a zero in its place.
"fermi_tmp_.F", line 516: 1525-096 A data item processed during an integer
read is too large.  The program will recover by assigning the data item the
value 2147483647.
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '-' in the input file.  The program will
recover by assuming a zero in its place.
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '.' in the input file.  The program will
recover by assuming a zero in its place.
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit 'E' in the input file.  The program will
recover by assuming a zero in its place.
"fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '-' in the input file.  The program will
recover by assuming a zero in its place.

   People from RES had to change the source code in order to get a
successful compilation, but I do not believe that this is the cause of our
problems.
   I have searched the mailing list without any help and I would really
appreciate if someone could give us any hint.
   Below, I show some information that I believe may be relevant, but if
you need any other information, please, ask.
   Many thanks in advance,
                                Luis Ogando

======================================================================================================================

Processor: IBM PowrPC 970+
Compilers: XLC 11.1 and XLF 13.1
MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version, parallel
version not yet tested)
======================================================================================================================
Compilation options for sequential version:
O   Compiler options:        -qfree=f90 -O5 -qstrict -q64
-qextname=flush -qdpc
 L   Linker Flags:            $(FOPT) -L../SRC_lib -lpthread
-L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
-L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath
 P   Preprocessor flags       '-WF,-DParallel'
 R   R_LIB (LAPACK+BLAS):     -lgoto2
======================================================================================================================
Compilation options for parallel version (again, the problem occurs in the
sequential version, parallel version not yet tested)
    RP  RP_LIB(SCALAPACK+PBLAS): -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
-L/gpfs/apps/GOTO2/64 -L/gpfs/apps/FFTW/3.3/64/double-xlf/lib
-L/opt/osshpc/mpich-mx/64/lib/ -lgoto2 -lscalapack -lmpich -lfftw3_mpi
-lfftw3
     FP  FPOPT(par.comp.options): -qfree=f90 -O5 -qstrict -q64
-WF,-DFFTW3 -qextname=flush
     MP  MPIRUN command        : mpirun -np _NP_ -machinefile _HOSTS_
_EXEC_

======================================================================================================================
case.dayfile:
Calculating InPzb in /gpfs/home_apps/home/vlc54/vlc54925/Wien/InP/InPzb
on s01c2b11 with PID 17405
using WIEN2k_12.1 (Release 22/7/2012) in /gpfs/home_apps/apps/WIEN2K/12.1

    start (Fri Mar 15 14:10:53 CET 2013) with lapw0 (40/99 to go)

    cycle 1 (Fri Mar 15 14:10:53 CET 2013) (40/99 to go)

>   lapw0 (14:10:53) 10.373u 0.274s 0:10.90 97.6% 0+0k 0+0io 1pf+0w
>   lapw1     -c (14:11:04) 1.489u 0.117s 0:01.67 95.2% 0+0k 0+0io 0pf+0w
>   lapw2    -c (14:11:06) Segmentation fault
0.064u 0.033s 0:00.15 60.0% 0+0k 0+0io 0pf+0w
error: command   /gpfs/home_apps/apps/WIEN2K/12.1/lapw2c lapw2.def   failed

>   stop error
======================================================================================================================

:log
>   (init_lapw) options:
Fri Mar 15 14:05:44 CET 2013> (x_lapw) nn -f InPzb
Fri Mar 15 14:05:53 CET 2013> (x) nn
Fri Mar 15 14:06:03 CET 2013> (x) sgroup
Fri Mar 15 14:06:14 CET 2013> (x) symmetry
Fri Mar 15 14:06:33 CET 2013> (x) lstart
Fri Mar 15 14:07:24 CET 2013> (x) kgen
Fri Mar 15 14:07:34 CET 2013> (x) dstart -c
>   (run_lapw) options: -NI -ec 0.0001
Fri Mar 15 14:10:53 CET 2013> (x) lapw0
Fri Mar 15 14:11:04 CET 2013> (x) lapw1 -c
Fri Mar 15 14:11:06 CET 2013> (x) lapw2 -c
======================================================================================================================

case.struct (initialized with default parameters and 10 inequivalent
k-points)

InP

F   LATTICE,NONEQUIV.ATOMS:  2216_F-43m

MODE OF CALC=RELA unit=ang

  11.23584  11.23584  11.23584  90.00000  90.00000  90.00000

ATOM   1: X=0.00000000 Y=0.00000000 Z=0.00000000
          MULT= 1          ISPLIT= 2
In         NPT=  781  R0=0.00001000 RMT=   2.50000   Z: 49.0

LOCAL ROT MATRIX:    1.0000000 0.0000000 0.0000000
                     0.0000000 1.0000000 0.0000000
                     0.0000000 0.0000000 1.0000000
ATOM   2: X=0.25000000 Y=0.25000000 Z=0.25000000
          MULT= 1          ISPLIT= 2
P          NPT=  781  R0=0.00010000 RMT=   2.12      Z: 15.0

LOCAL ROT MATRIX:    1.0000000 0.0000000 0.0000000
                     0.0000000 1.0000000 0.0000000
                     0.0000000 0.0000000 1.0000000
  24      NUMBER OF SYMMETRY OPERATIONS
 1 0 0 0.00000000
 0-1 0 0.00000000
 0 0-1 0.00000000
       1
 1 0 0 0.00000000
 0 0-1 0.00000000
 0-1 0 0.00000000
       2
 0 1 0 0.00000000
-1 0 0 0.00000000
 0 0-1 0.00000000
       3
 0 0 1 0.00000000
-1 0 0 0.00000000
 0-1 0 0.00000000
       4
 0 1 0 0.00000000
 0 0-1 0.00000000
-1 0 0 0.00000000
       5
 0 0 1 0.00000000
 0-1 0 0.00000000
-1 0 0 0.00000000
       6
 0-1 0 0.00000000
 1 0 0 0.00000000
 0 0-1 0.00000000
       7
 0 0-1 0.00000000
 1 0 0 0.00000000
 0-1 0 0.00000000
       8
-1 0 0 0.00000000
 0 1 0 0.00000000
 0 0-1 0.00000000
       9
-1 0 0 0.00000000
 0 0 1 0.00000000
 0-1 0 0.00000000
      10
 0-1 0 0.00000000
 0 0-1 0.00000000
 1 0 0 0.00000000
      11
 0 0-1 0.00000000
 0-1 0 0.00000000
 1 0 0 0.00000000
      12
 0 0 1 0.00000000
 0 1 0 0.00000000
 1 0 0 0.00000000
      13
 0 1 0 0.00000000
 0 0 1 0.00000000
 1 0 0 0.00000000
      14
-1 0 0 0.00000000
 0 0-1 0.00000000
 0 1 0 0.00000000
      15
-1 0 0 0.00000000
 0-1 0 0.00000000
 0 0 1 0.00000000
      16
 0 0 1 0.00000000
 1 0 0 0.00000000
 0 1 0 0.00000000
      17
 0 1 0 0.00000000
 1 0 0 0.00000000
 0 0 1 0.00000000
      18
 0 0-1 0.00000000
 0 1 0 0.00000000
-1 0 0 0.00000000
      19
 0-1 0 0.00000000
 0 0 1 0.00000000
-1 0 0 0.00000000
      20
 0 0-1 0.00000000
-1 0 0 0.00000000
 0 1 0 0.00000000
      21
 0-1 0 0.00000000
-1 0 0 0.00000000
 0 0 1 0.00000000
      22
 1 0 0 0.00000000
 0 0 1 0.00000000
 0 1 0 0.00000000
      23
 1 0 0 0.00000000
 0 1 0 0.00000000
 0 0 1 0.00000000
      24
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/0191ba04/attachment.htm>