09 May 2012

146. Nwchem with openblas

Openblas seems to be the successor of Gotoblas. http://xianyi.github.com/OpenBLAS/
I willingly admit that I am no expert on this blas library stuff, so I may well be doing something obviously wrong.

1. Compiling and installing openblas
sudo mkdir /opt/openblas
sudo chown ${USER} /opt/openblas
mkdir ~/tmp
cd ~/tmp

download from here http://github.com/xianyi/OpenBLAS/tarball/v0.1.1

tar xvf xianyi-OpenBLAS-v0.1.1-0-g5b7f443.tar.gz

 make all BINARY=64 CC=/usr/bin/gcc FC=/usr/bin/gfortran USE_THREAD=0 INTERFACE64=1 1> make.log 2>make.err

make PREFIX=/opt/openblas install
cp lib*.*  /opt/openblas/lib

cd /opt/openblas/lib
rm libopenblas.so.0
ln -s libopenblas.so libopenblas.so.0

do ls /opt/openblas/lib and note what cpu specific file you have such as libopenblas_barcelona-r0.1.1.so or libopenblas_nehalem-r0.1.1.a

edit /etc/ld.so.conf and add
/opt/openblas/lib

2. Compiling nwchem

sudo apt-get install build-essential gfortran python2.7-dev
mkdir /opt/nwchem/
sudo chown ${USER} /opt/nwchem
cd /opt/nwchem
wget http://www.nwchem-sw.org/images/Nwchem-6.0.tar.gz
tar -xvf Nwchem-6.0.tar.gz
cd nwchem-6.0/


For python support, edit src/config/makefile.h and add -lz -lssl to line 1962 (see here: http://verahill.blogspot.com.au/2012/04/adding-python-support-to-nwchem-under.html)

Next, continue
export LARGE_FILES=TRUE
export TCGRSH=/usr/bin/ssh
export NWCHEM_TOP=`pwd`
export NWCHEM_TARGET=LINUX64
export NWCHEM_MODULES="all python"
export PYTHONHOME=/usr
export PYTHONVERSION=2.7
export USE_MPI=y
export USE_MPIF=y
export MPI_LOC=/usr/lib/openmpi/lib
export MPI_INCLUDE=/usr/lib/openmpi/include
export BLASOPT="-L/opt/openblas/lib -lopenblas -lopenblas_barcelona-r0.1.1"
export LIBRARY_PATH=$LIBRARY_PATH:/usr/lib/openmpi/lib
export LIBMPI="-lmpi -lopen-rte -lopen-pal -ldl -lmpi_f77 -lpthread"
cd $NWCHEM_TOP/src
make clean
make nwchem_config
make FC=gfortran

Now edit your ~/.bashrc and add
export PATH=$PATH:/opt/nwchem/nwchem-6.0/bin/LINUX64
export LD_LIBRARY_PATH=/opt/openblas/lib:$LD_LIBRARY_PATH 
and you should be done.

You might find that ecce still won't properly execute nwchem jobs (you don't get an error -- it just doesn't work) -- edit your /etc/ld.so.conf and add a line saying

/opt/openblas/lib

Then do sudo ldconfig and it will work


Time to look into benchmarking...


So far I've got the following benchmarks (in seconds) for nwchem when optimising benzene with 6-311++g** using mpirun -n 3.

without -lpthread
_____Internal blas_____openblas_____ATLAS_____acml_____
Ta     249.8                    277.7                 335.9           ------
Be     408.2                    421.7                 568.4        
B      546.4                     579.9                 760.2        

Noticing a mention regarding -lpthread online I compiled with that as part of the mpilibs, and lo and behold:

with -lpthread

_____Internal blas_____openblas_____ATLAS_____acml_____
Ta      201.7                    198.9                233.9           ------
Be      371.1                    314.4                390.3        
B        496.6                    416.8                 521.9

* All run using mpirun -n 3. Be=phenom II X6. B= Athlon II X3. Ta= i7-1600 X4. Intel MKL cost money, acml are free.

This doesn't mean that one library is superior to the other -- it just means that under the conditions I employed and in the presence of any mistake I may have made, these are my observations. Your mileage will vary.

08 May 2012

145. Rasmol on ROCKS 5.4.3

By request:

This shows how to install rasmol on ROCKS 5.4.3 which is based on CentOS.

Rasmol 2.7.5.2
wget http://www.rasmol.org/software/RasMol_Latest.tar.gz
tar xvf
cd RasMol-2.7.5.2/src/
./build_all.sh

If all went well
sh rasmol_run.sh
should start it

NOTE: this doesn't install rasmol anywhere -- it builds it and allows you to run it from the src directory. Put an alias in your ~/.bashrc  pointing towards the rasmol_run script e.g.
alias rasmol='sh /home/me/.rasmol/RasMol-2.7.5.2/src/rasmol_run.sh'

Note that prior to this you will have to set up a working build environment, e.g.
sudo yum install gcc gcc-c++ gcc-gfortran cpp

07 May 2012

144. [Fixed] Upgraded ECCE (6.2 -> 6.3) won't let you save input files, can't write basis etc.

Update 1/6/2012: As always there's a better, smarter way of doing this, and as usual it involves reading the manual, or in this case reading the documentation that comes with ecce:
"... you had issues upgrading from ECCE 6.2 to 6.3 in regards to ECCE not being able to find scripts it needed to generate input files such as creating basis sets. Your solution was the manual way for something that is a basic part of ECCE setup for users (maybe you've since figured this out). There is a $ECCE_HOME/scripts/runtime_setup.sh sh/bash environment setup script that you can invoke to set up the paths as needed. This is documented in the list of steps needed when you install ECCE after it is done extracting the distribution right before the install finishes. When you actually invoke ecce then the rest of the environment (such as putting the scripts/parsers directory in the path) is done by the ecce_env script."

From what I understand the path which is set is ECCE_HOME and $ECCE_HOME/scripts is the added to PATH. But that's not enough. I think the 'word too long' thingy is playing up again.

The problem:
After upgrading ecce from 6.2 to 6.3 I keep getting errors of this type after drawing a structure, and then choosing a basis set:

ERROR: Input files could not be generated--failed writing basis set
Calculation saved as small.

And yes, no input files are generated.

Since I launch ecce from the terminal, I get the following error messages when I try to launch nwchem jobs:

sh: 1: std2NWChem: not found

and gaussian jobs:
sh: 1: std2Gaussian-03: not found

Unrelated: I also get a lot of
Word too long.
Word too long.
Word too long.
Word too long.
which has to do with csh somehow. I am not a fan of csh.

My ecce-6.3/apps/siteconfig/CONFIG.beryllium looks correct.

The investigation:

First, in ecce-6.3
 cat */*/*/*|strings|grep std2
[..]
std2GAMESS(US)          - Script that translates basis set from standard
std2Gaussian-92         - Identical to std2Gaussian-94.
std2Gaussian-94         - Script that translates basis set from standard
std2NWChem              - Script that translates basis set from standard
[..]
At least now we know what its related to.
tail -n 9999 */*/*/*|strings|egrep "std2|<=="
==> apps/scripts/parsers/README <==
   "std2Gaussian-94".
std2GAMESS(US)          - Script that translates basis set from standard
std2Gaussian-92         - Identical to std2Gaussian-94.
std2Gaussian-94         - Script that translates basis set from standard
std2NWChem              - Script that translates basis set from standard
locate std2
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Amica
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2GAMESS-UK
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2GAMESS-US
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Gaussian-03
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Gaussian-92
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Gaussian-94
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Gaussian-98
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Hondo
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2Meldef
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2NWChem
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2aceII
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2molcas
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2molpro
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2supermolecule
/home/me/.ecce/ecce-6.3/apps/scripts/parsers/std2tx93
apps/scripts/ecce_env shows that ecce checks whether parsers is in path -- and adds the parsers directory if it isn't:

if (`echo $PATH | grep -c "${ECCE_HOME}/scripts/parsers"` == 0 ) then
  set path = (${ECCE_HOME}/scripts/parsers $path)
endif

Something seems to go wrong here.

The solution

Add this to ~/.bashrc
export ECCE_HOME=/home/me/.ecce/ecce-6.3/apps
export PATH=${ECCE_HOME}/scripts:
${ECCE_HOME}/scripts/parsers
:${PATH}