1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139

#! /bin/bash
 
# Script to extract the atomic positions (xyz) from 
# POSCAR & OUTCAR files of VASP and write them to a 
# file, to be used with Jmol, MolDen and such other
# third party programs
 
# First written: Gowtham, Tue, 22 Dec 2009 11:11:12 -0500
# Last modified: Gowtham, Tue, 22 Dec 2009 16:29:36 -0500
 
# Essential VASP Files
# If missing, quit the program
export POSCAR="POSCAR"
export OUTCAR="OUTCAR"
 
if [[ -e $POSCAR || -e $OUTCAR ]];
then
  echo
  echo "  $POSCAR & $OUTCAR found"
else
  echo
  echo "  ERROR : POSCAR &/or OUTCAR missing"
  echo
  exit
fi
 
# Output Filename 
# If missing, quit the program
export OUTPUT=$1
 
if [ $# != 1 ];
then
  echo
  echo "  ERROR : OUTPUT_FILENAME Missing"
  echo "  Usage : vasp2xyz.sh OUTPUT_FILENAME"
  echo
  exit
fi
 
# Delete scratch files
rm -f Final.tmp.*
rm -f $OUTPUT.xyz
 
# Atoms related information
# Extracted from POSCAR & OUTCAR
 
# Total number of atom types
# Pat Krogel: Tue, 22 Dec 2009 13:13:48 -050
declare -a ATOM_TYPE=(`sed -n '6 p' $POSCAR`)
export ATOM_TYPE_TOTAL=${#ATOM_TYPE[@]}
 
# Total number of atoms
export ATOMS_TOTAL=0
export i=0
while [[ "$i" -lt "$ATOM_TYPE_TOTAL" ]];
do
  export iATOM_TYPE=${ATOM_TYPE[$i]}
  export ATOMS_TOTAL=`expr $ATOMS_TOTAL + $iATOM_TYPE`
  export i=`expr $i + 1`
done
 
# Atom labels
declare -a ATOM_LABEL=(`grep "POTCAR:" $OUTCAR | head -$ATOM_TYPE_TOTAL | awk '{print $3}' | sed -e 's/_.*//g'`)
export ATOM_LABEL_TOTAL=${#ATOM_LABEL[@]}
 
# Print2Screen
if [[ "$ATOM_TYPE_TOTAL" != "$ATOM_LABEL_TOTAL" ]];
then
  echo
  echo "  ERROR : Atom Type Total ($ATOM_TYPE_TOTAL) does NOT"
  echo "          match Atom Label Count ($ATOM_LABEL_COUNT)"
  echo "  Please make sure OUTCAR & POSCAR are from the same"
  echo "  system and calculation"
  echo 
  exit
else
  echo
  echo "  Number of Atom Types   :" $ATOM_TYPE_TOTAL
  echo "  Atom Type              :" ${ATOM_LABEL[@]}
  echo "  Atom Type Count        :" ${ATOM_TYPE[@]}
  echo "  Total Number of Atoms  :" $ATOMS_TOTAL
 
  # ATOM_LABEL_2 is an array of atom labels
  # with each atom label appearing an appropriate
  # number of times, to a total of $ATOMS_TOTAL
  declare -a ATOM_LABEL_2
  export REPEAT=0
  export j=0
 
  while [[ "$j" -lt "$ATOM_TYPE_TOTAL" ]]; 
  do
    export k=1
 
    while [[ "$k" -le "${ATOM_TYPE[$j]}" ]]; 
    do
      export REPEAT=`expr $REPEAT + 1`
      export k=`expr $k + 1`
      ATOM_LABEL_2[$REPEAT]=${ATOM_LABEL[$j]}
    done
 
    export j=`expr $j + 1`
  done
# echo ${ATOM_LABEL_2[@]}
# echo ${#ATOM_LABEL_2[@]}
 
  # Record the line numbers where coordinates are written
  # in OUTCAR. Actual coordinates begin 2 lines below
  # the recorded numbers
  grep -n "POSITION" $OUTCAR | sed -e 's/:/ /g' | sed -e 's/POSITION.*//g' > LINE_NUMBERS.tmp
 
  export FRAME_NUMBER=1
  while read START
  do
    export START_HERE=`expr $START + 2`
    export END_HERE=`expr $START_HERE + $ATOMS_TOTAL - 1`
 
    echo "$ATOMS_TOTAL" >> $OUTPUT.xyz
    echo "# Frame Number: $FRAME_NUMBER" >> $OUTPUT.xyz
    sed -n "$START_HERE,$END_HERE p" $OUTCAR | awk '{printf "%12.8f %12.8f %12.8f\n", $1, $2, $3}' > Final.tmp.$FRAME_NUMBER
 
    export l=1
    while read X Y Z
    do
      echo ${ATOM_LABEL_2[$l]} $X $Y $Z > Final.tmp.$FRAME_NUMBER.$l
      awk '{ printf "%-3s %12.8f %12.8f %12.8f\n", $1, $2, $3, $4 }' Final.tmp.$FRAME_NUMBER.$l >> $OUTPUT.xyz
      export l=`expr $l + 1`
    done<Final.tmp.$FRAME_NUMBER
 
    export FRAME_NUMBER=`expr $FRAME_NUMBER + 1`
  done<LINE_NUMBERS.tmp
 
  export FRAMES_TOTAL=`expr $FRAME_NUMBER - 1`
  echo "  Total Number of Frames :" $FRAMES_TOTAL
  echo
fi
 
# Delete scratch files
rm -f LINE_NUMBERS.tmp 
rm -f Final.tmp.*

Test Case

If POSCAR and OUTCAR aren’t handily available for testing, one could download the following:

POSCAR | OUTCAR

Running vasp2xyz.sh

Resulting xyz file

xyz file visualized with Jmol

If you have suggestions to make this better/efficient, please do post them as comments.

We (as in our research group at Michigan Tech) have had a trial account on JUMP and JUBL in Jon von Neumann Institute of Computing, Jülich. But not having enough success, at least until recently, to get SIESTA/SMEAGOL compiled/running on our own beowulf linux cluster prevented me from pursuing similar attempts on JUMP/JUBL. Also, my inability to understand, let alone solve, the error messages spit out during many a futile attempts (on JUMP) didn’t really help much and neither did the 6 hour time difference between Houghton and Jülich.

Work week at the NIC/CBB got off to a most unlikely of starts, but a very pleasant one indeed – Champagne Party!! I don’t recall any meeting, let alone the first thing on a Monday morning, to begin with sipping Champagne. This party was in celebration of CBSB 07 success but like every such meeting, it also did a detailed post-mortem of the workshop itself – what went right, what went wrong, what was done better compared to previous edition, what could be done better in subsequent editions, possible locations for CBSB 08 … and so on.

Much of my working time at NIC/CBB was spent in making many parts of the source code XL Compilers compliant and fortunately enough, SMEAGOL compiled and test runs successfully finished on JUBL around 4:58pm Friday! Otherwise, weekend ahead would have been really loooong and so would have been the return journey. A successful compilation/execution of SMEAGOL implicitly implies the same about SIESTA and as an added bonus, one other group that successfully compiled and tested VASP on JUBL sent us the Makefile (and are willing to help us more, if need be)

Our test calculation running on JUMP

JUBL – 8 racks of IBM BlueGene/L

Working and discussing things with Jan as well as almost every member of the NIC/CBB group (discussions weren’t always about computers and/or sciences) has taught me many things: I think I know a bit more about IBM BlueGene; understand the term compiler strictness (I had very little or no such understanding when Dr. Roberto Orlando had mentioned it a in ASCS workshop); understand the compile-time error messages better and know how to fix some of them at least. Probably the most important lesson of all was the following:

Hope (that things will somehow work out for good) – when combined with patience, perseverance and practice – is a really good thing

PS: If you/your group have an access to BlueGene/L at Jülich or elsewhere and are trying to get these programs working, do not hesitate to contact for Makefile tips, source code editions, etc. You may just post your question as a comment in the form below and I will respond at my earliest.

Now, how are these two related to each other, you ask? Ever since changing majors from pure Physics to Engineering Physics, Santa (yeah, the Santa) has been bringing me a wonderful Christmas gift – a gift of a unique kind that nerds and geeks would understand and appreciate. Last year, in 2005 December, it was the solution to the bugging problem of VASP compilation. And since then, I have been a good person, tried to stay away from troubles and such blah blah blah… For the past few months, I have been attempting to compile two programs – SIESTA being one of them. And this time, for Christmas, Santa (yeah, the same Santa) completely forgot about my gift (solution to the bugging compilation/run time errors associated with SIESTA) – or so I thought.

Three weeks after Christmas and two weeks into the New Year, all of a sudden Santa stops by to deliver my gift! I finally get some workable solution to the problem – the one that’s been bugging me for over two months. And if you have been a regular reader of these entries, you would have read it here. Santa not only gave me my gift but also explained as to why I was the last person on his list. And therein lies the relation between global warming and SIESTA! According to Santa’s usual gift-distributing route, he starts from North pole, goes down to South pole via Houghton and returns back to North pole via Denver. But this time around, Houghton did not receive its usual share of snow by Christmas (global warming – makes sense?) thus forcing Santa to reverse his route. He went to South pole via Denver (they got all the snow in Christmas; global warming again – makes more sense?) and stopped in Houghton on his way back to North pole… We have been getting some snow off late and Lake Superior has started to freeze – at least near the shores…

Freezing Lake Superior Shores near Baraga, MI

Freezing Lake Superior Shores near Baraga, MI

Well, Santa did his part and so did /me – I have spent countably infinite hours and attempts to compile these programs and quite many people (around the globe) have helped in this regard – some directly and some indirectly. Though the problem still has some unexplicable inconsistency when it comes to running on multiple processors, what helped the most were the ones shown in the picture below – a lot of them too:

Coffee, Chai and Beer — Catalysts in Compilation

Well, it is here that my semi-treatise on the relation between SIESTA and Global Warming ends – if you haven’t realized that the latter is affecting your lifestyle, aspirations, compilations, and such – be warned – you have been living in your own damned sweet little universe. It’s about time to wake up and do something about it – so that I get my Christmas gifts on time

I got in touch with few of Intel’s authorized resellers (one in Bloomington, MN – who transferred the call to someone else in Boston, MA) to see if I can get a copy of version 8.x of FORTRAN and C compilers. Though the latter person promised to get back to me with some favorable information soon, I got directly in touch with an Intel Support Technician – hoping that he/she wouldn’t be from a call center in some other country. Fortunately, it was somebody in California and unfortunately, he redirected me back to their re-sellers. Last call, pretty much out of desperation, did what I wanted : I just had to register the non-commercially downloaded products for Premier Support and I would be entitled for previous versions too. If only Intel explicitly mentioned what Premier Support actually is, my worries would have ended a long time ago. By the way, if you are now wondering what the error message was (running on 2 processors), here it is:

1
2
3
4
5
6
7
8
9
10
11
12
13

running on    2 nodes
distr:  one band on    1 nodes,    2 groups
vasp.4.6.28 25Jul05 complex
POSCAR found :  4 types and   18 ions
LDA part: xc-table for Ceperly-Alder, standard interpolation
found WAVECAR, reading the header
POSCAR, INCAR and KPOINTS ok, starting setup
WARNING: wrap around errors must be expected
FFT: planning ...           1
reading WAVECAR
the WAVECAR file was read sucessfully
LAPACK: Routine ZPOTRF failed!           8
LAPACK: Routine ZPOTRF failed!           8

Having managed to get version 8.x and 7.x of Intel compilers, situation only got worse as the error message remained the same At this point, I must thank the help offered by VASP Tech Support and Andri Arnaldsson (from University of Washington) – they have been pretty quick in their responses, sent their copies of Makefiles along with several tips and tricks. Changing compiler versions, using a previous version of MPICH (1.2.7p1 to be precise), repeating compilation many times with different BLAS, LAPACK libraries … nothing helped.

Taking a break for an hour and watching an episode of South Park seemed to have helped. A modification in the key words used for Google! search and reading some discussion forum lot more carefully, I found that adding three lines at the end of VASP Makefile (what this does is to reduce the level of optimization for mpi.F), the error vanished and the calculations started running smoothly. I repeated the same calculation using 2, 4, 6 and 8 processors and noticed a slightly strange behavior – when the number of processors was 2, 4 or 8, energy optimization is exactly same as in a serial calculation but when the number of processors is 2*N (N=3 in this case), energy optimization route is different – final result is still exactly the same. Though I have to do more trials (say 3, 5, 7, 9, 10 processors) to completely convince myself, it appears to me that using 2^N processors does the trick. Like Dave Kraus mentioned once before – knowing what trick works is certainly important, but knowing why that trick works is even more important.