VASP runtime error

Message

cdt9f · #1 Post by **cdt9f** » Mon Nov 14, 2005 3:46 pm

I am getting the following error when I run VASP on a new system. I originally thought the problem could be fixed by changing the "real_size" tag or "check bounds" tag for the fortran compiler (originally I was getting the runtime error: "forrtl: error (72): floating overflow", now, after playing with those tags, I get the error shown below). Any help would be appreciated.

Chris

running on 4 nodes
distr: one band on 1 nodes, 4 groups
vasp.4.6.27 26Jun05 complex
POSCAR found : 1 types and 7 ions
WARNING: for PREC=h ENMAX is automatically increase by 25 %
this was not the case for versions prior to vasp.4.4
LDA part: xc-table for Ceperly-Alder, standard interpolation
POSCAR, INCAR and KPOINTS ok, starting setup
WARNING: wrap around errors must be expected
forrtl: severe (139): array index out of bounds for index 1 (SIGTRAP)

cdt9f · #2 Post by **cdt9f** » Fri Nov 18, 2005 6:20 pm

I think now that this must be a problem with mpi, since, looking at the stack trace:
#12 0x12007624c in m_bcast_i_from() "mpi.f":742
#13 0x1203865a4 in mapset() "fftmpi_map.f":159
#14 0x12003ddc0 in vamp() "main.f":1742
#15 0x12041e52c in main() "for_main.c":203
#16 0x120027bf8 in __start(...) in /usr/scratch/1/ctaylor/rundir/vasp

The error seems to be coming from an mpi call. Any hints?

Chris

#3 Post by **admin** » Wed Nov 23, 2005 2:48 pm

what fortran compiler / paralellization software (mpich.x, lam? ) do you use?

cdt9f · #4 Post by **cdt9f** » Wed Nov 23, 2005 3:45 pm

I am running on an ALPHA cluster using mpich-g2-gcc-mpi-1.2.6. The fortran compiler is Compaq Fortran 90.

Thanks for your time,
Chris

#5 Post by **admin** » Thu Dec 01, 2005 1:55 pm

if you change the variable-length compilation parameters, you should be careful that the lengths of those parameters which are passed to the mpi routines are compiled consistently in vasp and the mpich. please check if this is the case.
we have made the experience that using LAM for parallelisation
is much less prone to errors.