Showing posts with label ecce. Show all posts
Showing posts with label ecce. Show all posts

24 March 2013

369. Compiling ECCE 6.4 on Fedora 18

UPDATE 16 April 2013:
The getops.pl issues has now been fixed in the latest release of ECCE
(http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id756/Problem_with_httpd.html)

Original post
(there were initially some issues with getops.pl being deprecated. Fixed now)

This post on the NWChem/ECCE forum got me interested in trying to build ECCE on Fedora 18.

I'm presuming that you just clicked your way through the fedora 18 installation so that e.g.  java-1.7.0-openjdk is already installed.  Note that the default partitioning scheme in Fedora may lead to a very small (<1 Gb) /tmp partition, which may prevent you from building properly, so be aware.

Building form source will solve at the very least :
* the issues of there being no 32 bit binary (build your own)
* issues with ubuntu libraries (libXfixes) if you try to install an older 32 bit binary

You'll also have access to the source code which means that you could -- at least in theory -- contribute to the project by doing bug fixes.

Building is easy once you've got all dependencies figured out. The initial run of the build script misses the detection of two required sets of packages: openGL libs, and perl-Digest-MD5

Start here

1. Download
Go to http://ecce.emsl.pnl.gov/using/download.shtml, fill out the form, and download the source code on the next page (ecce-v6.4-src.tar.gz). Create the folder ~/tmp (mkdir ~/tmp) and put ecce-v6.4-src.tar.bz2 in ~/tmp

2. Prepare
tar xvf ecce-v6.4-src.tar.bz2
cd ecce-v6.4/
export ECCE_HOME=`pwd`
cd build/
sudo yum install vim csh gcc gcc-c++ gcc-gfortran java-1.7.0-openjdk-devel python-devel ant gtk2-devel libjpeg-turbo-devel libtool ImageMagick libXt-devel xterm mesa-libGLU-devel kernel-devel perl-Digest-Perl-MD5 perl-Digest-MD5

(if you're doing this in virtualbox, the way to get openGL libs is via the virtualbox guest additions, and in order to build those you'll need the kernel headers (kernel-devel package) for the currently running kernel)

3. Build
pwd
/home/verahill/tmp/ecce-v6.4/build
./build_ecce

The script will see if all the requirements are met by stating what version is needed and echoing the currently installed version of different dependencies. Presumably all of the requirements will be met after installing the dependencies in step 2. At the very end you'll be asked

Do you want to skip these checks for future build_ecce invocations (y/n)? Y

Answer Y. The run build_ecce again and again...

./build_ecce
Xerces built
./build_ecce
Mesa OpenGL built
./build_ecce
wxWidgets built
This step will fail if you don't have openGL libs installed.

./build_ecce
running build_ext wxPython built
./build_ecce
Apache HTTP server built
./build_ecce
Making combined tar file ecce.v6.4.tar Copying NWChem binary distribution nwchem-6.1.1-binary-rhel5-gcc4.1.2-m64.tar.bz2 Copying NWChem common distribution nwchem-6.1.1-binary-common.tar.bz2 Concatenating install script and combined tar file ecce.v6.4.tar create_ecce_bin finished ECCE built and distribution created in /home/verahill/tmp/ecce-v6.4
This step will fail with
make[2]: Leaving directory `/home/verahill/tmp/ecce-v6.4/src/apps/vizthumbnail'

make[1]: Leaving directory `/home/verahill/tmp/ecce-v6.4/src/apps'

Can't locate Digest/MD5.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /home/verahill/tmp/ecce-v6.4/build/create_ecce_bin line 37.

BEGIN failed--compilation aborted at /home/verahill/tmp/ecce-v6.4/build/create_ecce_bin line 37.

if you don't have perl-Digest-MD5 installed.


4. Installation
You can now install ecce:
cd ..
./install_ecce.v6.4.csh

and follow the instructions. This post has an overview of the installation process, as do several of the posts here: http://verahill.blogspot.com.au/p/compilinginstalling-software-for.html

5. Patching
getops.pl has been deprecated in perl 5 -- see under incompatible changes on this page: http://fedoraproject.org/wiki/Features/perl5.16
Luckily, the fix is simple:

Assuming that you install ECCE in ~/ecce-v6.4
cd ~/ecce-v6.4/apps/scripts
sed -i 's/require "getopts.pl";/use Getopt::Std;/g' *
sed: couldn't edit codereg: not a regular file
set -i 's/Getopts/getops/g' * cd parsers/ sed -i 's/require "getopts.pl";/use Getopt::Std;/g' * set -i 's/Getopts/getops/g' *

While getopts.pl has been deprecated, Getopt::Std supplies both a getop() and a getopts() function. I've done a little bit of testing (vib calcs, energy calcs) and so far everything looks great.

If you're still having issues, make sure that Getopt is in /usr/share/perl5

6. Run
You can now have fun with ECCE

28 February 2013

347. Minor ECCE oddity when pasting basis sets from BSE: lines longer than 254 chars wreak havoc

Using lines longer than 254 chars when editing nwchem input in ECCE leads to the rest of the input being dropped.

I discovered this when pasting basis sets from bse.pnl.gov. If you paste something which has a line longer than 254 chars, such as the one starting with # H He and ending with valence below (345 chars), everything that comes after that line will be dropped.
# Def2-SVP EMSL Basis Set Exchange Library 2/27/13 8:08 PM # Elements References # -------- ---------- # H He Li Be B C N O F Ne Na Mg Al Si P S Cl Ar K Ca Sc Ti V Cr Mn Fe Co Ni Cu Zn Ga Ge As Se Br Kr Rb Sr Y Zr Nb Mo Tc Ru Rh Pd Ag Cd In Sn Sb Te I Xe Cs Ba La Hf Ta W Re Os Ir Pt Au Hg Tl Pb Bi Po At Rn : F. Weigend and R. Ahlrichs, Phys. Chem. Chem. Phys., Balanced basis sets of split valence, triple zeta valence and quadruple zeta valence # quality for H to Rn: Design and assessment of accuracy 7, 3297 (2005). # BASIS "ao basis" PRINT #BASIS SET: (4s,1p) -> [2s,1p] H S 13.0107010 0.19682158E-01 1.9622572 0.13796524 0.44453796 0.47831935 H S 0.12194962 1.0000000 H P 0.8000000 1.0000000 #BASIS SET: (7s,4p,1d) -> [3s,2p,1d] O S 2266.1767785 -0.53431809926E-02 340.87010191 -0.39890039230E-01 77.363135167 -0.17853911985 21.479644940 -0.46427684959 6.6589433124 -0.44309745172 O S 0.80975975668 1.0000000 O S 0.25530772234 1.0000000 [..]

To reproduce, set up a calculation. In the editor, click on 'Final Edit'. Now paste your basis set. Save and exit (it's vi/m, so that means using :wq). 

Everything seems to be fine

Now, either select the job and hit Ctrl+I to see the input, or open the editor and click on 'Final Edit' again.

Nothing below the line immediately preceding the long line will be saved. It's not a visualisation issue either -- if you launch the job and do ctrl+o to see what NWChem received as input, it mirrors what you see as input.

Pasting anything other than that overly long line works fine.




A more artificial example would be to try to save this
a
b
abcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyz1234
d
e

which works, vs this:
a
b
abcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyzabcdefghijklmnopqrstuvxyz12345
d
e

which doesn't. There's a difference of one character.

23 January 2013

325. Compiling ECCE 6.4 on Debian Testing

!NOTE! If you provide ECCE with 'localhost' as the hostname, be aware that this will block outside access: http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id858/#post_3178

There's a new release of ECCE 6.4 out which fixes the following bug: http://verahill.blogspot.com.au/2012/11/minor-bug-in-ecce.html


A note on Java: I've only had luck with the openjdk packages -- not with the Oracle/sun java ones (see here: http://verahill.blogspot.com.au/2012/06/building-ecce-on-debian-testingwheezy.html).

This build was tested in a chrooted Testing/Wheezy i.e. I should've caught most of the necessary packages.


Compiling:
Download the source to ecce from http://ecce.emsl.pnl.gov/using/download.shtml, and put it in e.g. ~/tmp

sudo apt-get install bzip2 build-essential autoconf libtool ant pkg-config gtk+-2.0-dev libxt-dev csh gfortran openjdk-7-jdk python-dev libjpeg-dev imagemagick xterm
cd ~/tmp
tar xvf ecce-v6.4-src.tar.bz2
cd ecce-v6.4/
export ECCE_HOME=`pwd`
cd build/
./build_ecce
Hit return if xterm was found... The /home/sandbox/tmp/ecce-v6.4/scripts/sysdir script identifies the build platform directory as: empty Because this value is empty no platform-specific parent directory will be created for ECCE executables, libraries, etc. This works fine unless your site needs support for multiple platforms. Finished checking prerequisites for building ECCE. Do you want to skip these checks for future build_ecce invocations (y/n)? Y
./build_ecce
Xerces built
./build_ecce
Mesa OpenGL built
./build_ecce
wxWidgets built
./build_ecce
running build_ext wxPython built
./build_ecce
Apache HTTP server built
./build_ecce
Making combined tar file ecce.v6.4.tar Copying NWChem binary distribution nwchem-6.1.1-binary-rhel5-gcc4.1.2-m64.tar.bz2 Copying NWChem common distribution nwchem-6.1.1-binary-common.tar.bz2 Concatenating install script and combined tar file ecce.v6.4.tar create_ecce_bin finished ECCE built and distribution created in /home/sandbox/tmp/ecce-v6.4
cd ../ ./install_ecce.v6.4.csh

And see the next section for the installation steps.
The compilation steps take progressively longer and longer, so be patient during the build.

Installing:
Digital ink is cheap, so I'll show the whole process:
./install_ecce.v6.4.csh
Main ECCE installation menu =========================== 1) Help on main menu options 2) Prerequisite software check 3) Full install 4) Full upgrade 5) Application software install 6) Application software upgrade 7) Server install 8) Server upgrade IMPORTANT: If you are uncertain about any aspect of installing or running ECCE at your site, please refer to the detailed ECCE Installation and Administration Guide at http://ecce.pnl.gov/docs/installation/2864B-Installation.pdf Hit at prompts to accept the default value in brackets. Selection: [1] 3 Host name: [beryllium] localhost Application installation directory: [/home/sandbox/tmp/ecce-v6.4/ecce-v6.4/apps] /home/sandbox/.ecce/apps Server installation directory: [/home/sandbox/.ecce/server] ECCE v6.4 will be installed using the settings: Installation type: [full install] Host name: [localhost] Application installation directory: [/home/sandbox/.ecce/apps] Server installation directory: [/home/sandbox/.ecce/server] Are these choices correct (yes/no/quit)? [yes] Installing ECCE application software in /home/sandbox/.ecce/apps... Extracting application distribution... Extracting NWChem binary distribution... Extracting NWChem common distribution... Extracting client WebHelp distribution... Configuring application software... Configuring NWChem... Installing ECCE server in /home/sandbox/.ecce/server... Extracting data server in /home/sandbox/.ecce/server/httpd... Extracting data libraries in /home/sandbox/.ecce/server/data... Extracting Java Messaging Server in /home/sandbox/.ecce/server/activemq... Configuring ECCE server... ECCE installation succeeded. *************************************************************** !! You MUST perform the following steps in order to use ECCE !! -- Unless only the user 'sandbox' will be running ECCE, start the ECCE server as 'sandbox' with: /home/sandbox/.ecce/server/ecce-admin/start_ecce_server -- To register machines to run computational codes, please see the installation and compute resource registration manuals at http://ecce.pnl.gov/using/installguide.shtml -- Before running ECCE each user must source an environment setup script. For csh/tcsh users add this to ~/.cshrc: if ( -e /home/sandbox/.ecce/apps/scripts/runtime_setup ) then source /home/sandbox/.ecce/apps/scripts/runtime_setup endif For sh/bash users, add this to ~/.profile or ~/.bashrc: if [ -e /home/sandbox/.ecce/apps/scripts/runtime_setup.sh ]; then . /home/sandbox/.ecce/apps/scripts/runtime_setup.sh fi ***************************************************************

Instead of following the instructions above I normally do:
echo 'export ECCE_HOME=/home/sandbox/.ecce/apps' >> ~/.bashrc
echo 'PATH=$PATH:/home/sandbox/.ecce/server/ecce-admin/:/home/sandbox/.ecce/apps/scripts/' >> ~/.bashrc
echo 
source ~/.bashrc

You can now start ecce by either doing
ecce

or if that complains, do
start_ecce_server

then waiting a little while (10 s), followed by
ecce


Apppendix:

Selecting Java version
sudo update-alternatives --config java
There are 7 choices for the alternative java (providing /usr/bin/java). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 1061 auto mode 1 /usr/bin/gij-4.4 1044 manual mode 2 /usr/bin/gij-4.6 1046 manual mode 3 /usr/bin/gij-4.7 1047 manual mode 4 /usr/lib/jvm/j2re1.6-oracle/bin/java 314 manual mode 5 /usr/lib/jvm/j2sdk1.6-oracle/jre/bin/java 315 manual mode 6 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 1061 manual mode * 7 /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 1051 manual mode

I've got ECCE running fine with openjdk 7 as well as openjdk 6.

27 November 2012

285. Minor bug in ECCE

I'll classify this as a bug, since the specificity of it surely must mean that it is an unintended behaviour. Basically you lose your hand-edited changes in your input files if you're not careful.

By Editor I don't mean the vim editor, but rather then Job Editor in Ecce.

 A demonstation: 

1. Create an input in ECCE. In this case I created a single-point energy calculation of dioxygen. Hand-edit the input file by clicking on Final Edit and add e.g. maxiter 99 in the dft block.



 2. Run the job


 3. Open the Editor. With the Editor open, click on Run Mgmt/Reset for restart. (In spite of the figure below, it has nothing to do with whether the vim editor is open or not.)

 4. Your hand-edited changes are now gone.



 In contrast, if the Editor is not open when you click on Run Mgmt/Reset for restart the changes will be kept.

24 November 2012

281. Visualising NWChem output with GabEdit

Update: please read Karol's comment below. I will put a link here once I've written up a post on how to modify nwchem.

Update 2: Here's the post: http://verahill.blogspot.com.au/2013/02/3xx-modifying-nwchem-611-to-work-with.html .The conclusion is that you MUST edit nwchem. Luckily, it's easy.

Original post:
I've never liked Gabedit much (looks a bit dated, tries to do 'too much') -- until today. Suddenly I have a newfound respect for the developer(s) behind it. It actually doesn't try to do 'too much' -- it simply does A LOT, and actually does it in a pretty transparent way.

Long story short -- you can do things with gabedit which you can't do (easily) with ECCE, and as such it has become an important ally. Besides, it's always nice to have alternatives.

GabEdit is in the Debian repos.

Running your calculations
There are some restrictions"
1. NOTE: you must run your nwchem job with explicit basis sets (i.e. entered as text) -- to do that in ECCE tick the box as shown in the figure below. If you're running 'pure' nwchem, you (probably) have to cut and paste from the basis set directory -- see e.g. section 7.2 here. It's a minor convenience for gaining access to what GabEdit has to offer.


2. You can only open Single point/Energy calculations i.e. Optimizations won't work. So do a single point calculation on your optimized structure.

3. Also, you need to rename/copy your output file so that it ends with .out.
gabedit won't read it otherwise

GabEdit
It's fairly straightforward -- just point and click. One thing which you will want to play with are the iso-surface settings. The defaults are rarely good.

Anyway, I'll let the screenshots do the talking:

Go straight to the Output viewer -- Geometry/Orbital/Density
Click on the M, or right-click anywhere in the window, and load your renamed nwchem output file.


Here's triplet oxygen. The alpha, beta orbitals are listed in the right window

You can do electron localisation

Look at spin density (the unpaired electrons are in the anti-bonding  pi orbitals)

Contour plots are neat -- here showing spin density

Electrostatic potential. 


There's a lot to explore. GabEdit can obviously also prepare and submit jobs, but I'm happy with ECCE in this respect, and content with using GabEdit for post-processing.

28 October 2012

267. ECCE client connecting to remote site via reverse port/local port forwarding

The situation I'm about describe is quite specific, yet I don't think it's that unusual.

A. I've got a computer at work which is behind a firewall so that I can't connect directly to it from the outside. This will be referred to as Work.

B. I've got a laptop at home which is connected to a wireless  router. This will be referred to as Home.

C. The router is a Linksys/tomato router, which is accessible from the outside (myrouter.com). This will be referred to as Router.

I'd like to connect from home to my ecce server at work so that I can monitor and submit jobs.

At Work:
ssh -R 19997:localhost:8096 root@myrouter.com

At Home:
ssh -L 5555:localhost:19997 root@myrouter.com

We're basically tying together port 5555 at Home with port 8096 at Work, via an intermediary server.

At Home, edit your ecce/apps/siteconfig/Dataservers and change the relevant lines to

<eccedata>
  <ecceserver>
    <url>http://localhost:5555/Ecce</url>
    <desc>ECCE Data Server--remote</desc>
  </ecceserver>

  <basisset>http://localhost:5555/Ecce/system/GaussianBasisSetLibrary</basisset>
</eccedata>

Note that submission actually happens from your ecce client, not your server (i.e. from Home, not Work), so to get your submission scripts in order you may have to do a bit of fiddling. E.g. if you ecce server is also the queue master for an SGE batch system:

Work:
ssh -R 19999:localhost:22 root@myrouter.com

Home:
ssh -L 5454:localhost:19999 root@myrouter.com

Home:
Edit /apps/siteconfig/remote_shells.site and add
ssh_p5454: ssh -XC -p 5454|scp -P 5454|xterm

But you can read more about that here: http://verahill.blogspot.com.au/2012/05/port-redirection-with-eccenwchem.html

13 June 2012

189. Thoughts on restarting NWChem jobs in ECCE

UPDATE: Because all my nodes are working hard to keep my office warm in the Australian winter, I haven't tested this very extensively, but it seems like freq jobs can be restarted using
freq
           reuse oldhessian.hess
end
Original post
As often is the case, this is as much a note to myself as a blog post.

Or that's how it started out. I've since spent a bit of time testing different restart options, as I found that some paradoxically were actually seen to lead to longer calculations...

The jobs I've experimented with are very short, so the error margin is probably huge.

What I tried:

A. Task dft geometry:
1. Original job - 215 s
2. Substituting Start with restart in the same directory as A.1 (i.e. loaded db)  - 204 s
3. Same as A.2, but also deleted geometry section - 43 s
4. Same as A.2 and A.3, but loaded movecs explicitly - 43 s
5. Used start, but loaded movecs from job B.3. - 267 s

Comment: not sure whether A.5 is consistently slower than A.1, but I've never seen it go faster. A.3 looks like a good bet when resuming a calculation.

B. Task dft energy:
1. Original job - 41 s
2. Deleted geometry, loaded movecs, db from B.1 - 8.7 s
3. Used start directive, kept geometry, loaded movecs from B.1, no db - 8.7 s

Comment: loading movecs (B.3) seems like a winner

C. Task dft frequency
0. Original job - 952 s
1. Deleted geom, loaded movecs, db from task energy (B.2 above) - 853 s
2. Delete geometry, loaded movecs from opt, put drv.hess, .hess, fd_ddipole in same directory (from A.1 above) - 842 s
3. Same as C2, but deleted basis block as well, and removed everything from the dft block except direct and vectors - 849 s
4. Copied hessian from 0, and put 'reuse' inside the freq block - 0.1 s (!)
5. Copied hessian from A.1 and put 'reuse' inside the freq block - 0.1 s (but data wrong)


Comment: is C0 really slower than the other jobs?
The problem with approach C.5 is that while C.4 gives

65.943 kcal/mol, 69.553 cal/mol-K
C.5 gives
288.058 kcal/mol, 64.706 cal/mol-K


Here's a comment from one of the developers, Bert:

"If you just want to redo an energy calculation followed by and ESP calculation, I would never use restart, but just use start and define the geometry in the geometry block. [cut] The restart is purely to continue the calculation that got interrupted, and the runtime database is probably not in a clean enough state to do something completely different with it. You can use the movecs that have been generated as the starting vectors though. "

A.5 (no effect) and B.3 (speed-up) would be in line with that approach.

With that in hand, time to work on ECCE.

ECCE is a nice tool, but as any point-and-click program it has it's limitations -- it's impossible to predict every single type of usage, and this is particularly true for computational wizardry. To a large extent this is compensated for by the ability to do a 'final edit' using vim before submitting a job -- there is obviously nothing whatsoever that you're prevented from doing at this point, so it offer ultimate flexibility.

There is a major weakness using ECCE though -- using files from old jobs.

In particular this is a weakness when it comes to restarting jobs. In terms of structure, this isn't a problem -- the last structure is provided by ecce via ecce.out.  It would be nice to able to carry over the .movecs files though (I'm still learning, but loading movecs and using fragment guess seems to be the neatest thing). This is high on the wish list.

Anyway, there are two major use cases:

Restarting an interrupted job
Assuming that you resubmit it without changing the name and to the same cluster so that it'll run remotely in the same directory:

Replace
Start
with
restart 
which should tell nwchem to look for the .db file and
either edit the scf or dft block and add
vectors input jobname.movecs
Obviously, this isn't example of great insight, but rather a product of reading the manual.

Also, the manual does state (but does not suggest) that leaving the start/restart directive out would cause nwchem to look for evidence of whether it's a restarted job or not. The problem is that ECCE automatically names all files nwch.nw, which would cause nwchem to look for nwch.db and fail.


Launching a new calculation based on an old job
Now, if you are duplicating a job, or if you've since renamed the job, you're in a spot of trouble since ecce doesn't concern itself with the .db and .movecs files. Maybe there's a good reason for this? But if I understand everything correctly, this means that you are loosing a lot of time on scf cycles which you could avoid by loading the .movecs and .db file.

I think that in the case of: same cluster and similar directory structure (i.e. the previous job is also a subdirectory of the same parent directory as the new job) you can put this at the beginning of your job
task shell "cp ../oldjob/*.movecs ."

and either edit the scf or dft block and add
vectors input jobname.movecs

and it actually works.

But I had no luck doing this
task shell "cp ../oldjob/*.db ."
And combining it with restart -- it wants the .db file to be there already if you use restart. This, at least in terms of functionality, agrees well with the comment by Bert above - same directory is ok, but with a different directory only movecs are reasonably easy.

Now, all we need is a tick box to copy the old movecs files between jobs...and the underlying structure. At the moment the movecs files don't get imported, so it would take a bit of editing to get to that point.


07 June 2012

179. Building ECCE on Debian Testing/Wheezy

UPDATE: Build went fine. Upgrade went fine. But the organizer doesn't show my jobs properly i.e. the files are there but they aren't recognised as jobs. I haven't had a solid look at this yet, and it might just be because I need to restart more services than just the http server. It's been a long day...

UPDATE 2: An update on a different computer went without a hitch, with all the old job files being imported properly.

UPDATE 3: I started ECCE and let the data manger chew on it for four hours. No luck on the troublesome computer. The only difference is the java -- openjdk 7 worked fine, oracle jre/jdk didn't. Dunno if this is the reason, but currently in the process of installing the binaries to see whether that works better. Updates will come...

UPDATE 4: Installing the prebuilt ECCE binaries did the trick. In summary: as far as I know you MUST use openjdk 7. SUN/Oracle Java does not appear to work. It's exhibited in a lack of ability to recognise old jobs as being...jobs rather than just folders and files.


POST BEGINS HERE:
I'm trying to document everything I'm doing these days, no matter how simple or (at least in retrospect) obvious it is.

Here's how to build the 4th of June 2012 version of ecce v6.3.

You need to be registered with EMSL/PNNL to download ecce. There are plans to open-source the software properly (i.e. no need to register) sometime this coming northern summer. But for now you need to be an academic group leader to have access.

(I originally posted a somewhat different post where I recommended making some changes to the build scripts re ECCE_HOME. Eventually I saw the light and realised the error of my ways)

Download ecce-v6.3.src.tar.bz2, and put it in a suitable folder, e.g. ~/tmp
cd ~/tmp
tar -xvf ecce-v6.3-src.tar.bz2
cd ecce-v6.3/
export ECCE_HOME=`pwd`
cd build/
./build_ecce

The first time you run ./build_ecce you'll be asked a series of questions relating to installed packages. If it's all good, answer
Do you want to skip these checks for future build_ecce invocations (y/n)? y
If anything came up, then read the message carefully and install the missing package.

NOTE: on one box I noticed different version of java and javac being found, as I had both openjdk 6 and 7 installed. I couldn't set javac to 6 but I could do
sudo update-alternatives --config java
and set it to openjdk 7.

[From my small, statistically unsound sample set Oracle/SUN java will NOT work.]

Then do ./build_ecce again. And again. And again. In all, I think you do it six or seven times - each time a new package is built.
I always get a
lib: No such file or directory.
at the end of the httpd build. Not sure why, but everything seems to be ok in spite of that.
Anyway, you know that you're done running ./build_ecce when you get
ECCE built and distribution created in /home/verahill/tmp/ecce-v6.3
At this point, you are ready to install
DO NOT USE ./install_ecce

GO UP ONE LEVEL AND DO
./install_ecce.v6.3.csh

But that's a different story. install_ecce will give you weird error messages about missing tar files. install_ecce.v6.3.csh on the other hand will work fine.

04 June 2012

173. ECCE in a virtual machine: step by step using virtualbox

!NOTE!
Pre-built binaries of ECCE now ONLY exist for 64 bit OS -- if you install a 32 bit version of debian you will have to compile ECCE yourself. It's not difficult, but please be aware of it.

!NOTE2! If you provide ECCE with 'localhost' as the hostname during installation, be aware that this will block outside access: http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id858/#post_3178

See this post for ECCE 6.4 of Debian 7 (wheezy): http://verahill.blogspot.com.au/2013/05/434-ecce-64-on-debian-7-in-32-bit.html
!NOTE!

Sadly, not everyone uses linux. Some even refuse to give it a proper consideration. Since the goal here is science rather than OS enlightenment, we'll have to accept that some people will have to run ECCE in a virtual machine rather than using it natively (something like WINE but going the other direction would be nice).

Win/Mac users should not be surprised if graphics heavy applications like ECCE don't run very fast in a virtual machine though, but they will be the source of that frustration themselves.

Here's the whole sequence from downloading an iso to having ECCE ready to submit jobs from inside a virtual machine.

I'm doing all these steps on linux since I simply don't use or have access to windows (other than as a very small virtualbox install), so let me know if there's anything which won't work on windows. I'm particularly interested in XP since that's what most people in academia still use.

You can of course use these instructions on a proper debian installation as well.

The only reason this post is so long is because of the number of screen shots. It is NOT COMPLICATED OR DIFFICULT, so don't be put off by the length.

Index:
1. Install virtualbox
2. Set up the machine
3. Download the debian iso
4. Install debian in virtualbox
5. Customize your debian installation
6. Installing ECCE
7. Setting up ECCE
8. Launching a test calc.
9. Moving files back and forth between virtual debian and windows


1. Install Virtualbox
I've tested this step in my virtual XP machine, so it should work fine on a 'real' XP machine.

Download the windows installer: http://download.virtualbox.org/virtualbox/4.1.16/VirtualBox-4.1.16-78094-Win.exe . If the link doesn't work, then go to https://www.virtualbox.org/wiki/Downloads

Start the installer. It appears to be a bit buggy since the 'back' button doesn't work, so make sure that you think about your choices. Otherwise starting over isn't that hard.

 ...and start. You'll get a warning about network interfaces being reset. That's fine.

You get five of those Unsigned driver thingy warnings -- a Microsoft protection racket if you'd ask me (compatibility assurance is a good thing -- forcing developers to pay for warnings to go away isn't). Just click continue.


When you're done, launch:



Download the extensions from here: http://download.virtualbox.org/virtualbox/4.1.16/Oracle_VM_VirtualBox_Extension_Pack-4.1.16-78094.vbox-extpack



Click on Machine, Preferences and select Exentions. Click on the small Blue rhomb with the orange triangle on it on the right side of the window, navigate your way to where you downloaded the extension and install it:

 And this is what it looks like when you're done:




2. Set up a new machine
Click on New. Follow the instructions.

A few things to think about:
* Assign a reasonable amount of RAM, whatever that means. I'd suggest 1-1.5 Gb if you have 4 Gb machine. I'm testing 512 Mb in this example to see what the lower requirements are.
* Definitely make your hard drive big enough from the beginning since expanding it isn't that easy.

Here's a series of screen grabs:

 Select Linux, Debian (64 bit if possible)
 Set the amount of RAM. The more the merrier, but leave enough for your OS.


 Use a dynamically expanding HDD.
 10 Gb is a good start, but you'll have to move computational files off of the virtual hard drive periodically. The underlying OS only uses a small amount of storage space, but ECCE -- depending on what you do in it -- can use a lot more.





3. Download the iso
Clicking the following URL will hopefully start a download:
http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/

If not, then have a look at this page: http://www.debian.org/distrib/netinst and click on AMD64 under Small CDs (180 Mb). This will get you the latest Debian Squeeze, which is a bit old but rock solid. Upgrading to testing is a breeze if you should want to do that later.


4. Installing Debian
Select your new machine, and click on settings.

 Click on Storage
 Mount the iso you downloaded
 When all is good it should look like this:
Hit OK.

Two things you'll need to know at this point:

  • Right CTRL is your 'host' key. Hit (right) CTRL to release the mouse from the virtual desktop
  • Switch between full-screen mode using (right) CTRL+f (host+f)

Now you're ready to start your virtual machine, so click on Start, which brings you to this:


Most of the choices are fairly simple to answer so I won't cover them.
I selected:
Hostname - vecce
Domain name -- (empty)
Pick the mirror country that correspond to the country you're in. As for the actual mirror server, the first choice is normally ok. You can see if your uni is on the list, which will make it even faster.
Don't type anything when it asks for root password (done twice) since it's better (imho) to use sudo.
Our new user is called ecce, and this user will automatically be granted sudo powers.

Once you get to the partitioning, make sure to select Manual, and follow the screenshots below:
 First you need to format your harddrive. Remember, by harddrive we're really talking about a file on your disk, so screwing this up will NOT affect your windows computer in any shape or form.







 Having a Swap partition for a virtual HDD makes absolutely no sense.


Now your base system will install, and you'll eventually get to this screen. De-select the graphical desktop environment since we want to save space and resources -- gnome is wonderful, but demanding. We'll put LXDE on it later.
Install grub to the MBR. Remember, our harddrive is still just a file on your physical harddrive.

That's basically it. Click continue in the screen below, and your virtual system will restart.
 And here's what'll great you on reboot:

You're now ready to log on and do some damage.

5. Customize your debian installation
So log on:

 Make sure you have working internet by e.g. doing
ping -c 3 google.com

Now, type
sudo apt-get install lxde
type your password (you'll get a warning about great reponsibilities etc.), and answer yes to any questions

Once the install has finished, type
sudo shutdown -r now
which will cause a reboot which will bring you to this screen:

I use gnome 3/gnome-shell myself, so I'm not particularly familiar with LXDE, so if anything looks weird in the following steps, that's why.

Log on:
You'll find your terminal (LXTerminal) by clicking on what constitutes the Start Menu down on the left:
First install a web browser (in this case chromium -- essentially a re-branded Chrome):
sudo apt-get install chromium-browser
Start chromium by clicking on the web browser icon in the panel launcher down in the bottom left corner:
6. Installing ECCE
Download ECCE:



Install csh by typing
sudo apt-get install csh 
in the terminal
Then do
cd ~/Downloads
chmod +x install_ecce.v6.3.rhel5-gcc4.1.2-m64
csh install_ecce.v6.3.rhel5-gcc4.1.2-m64
Select Full Install [3]

Change the hostname to localhost
Set the application install path to /home/ecce/ecce-v6.3/apps and the server directory to /home/ecce/ecce-v6.3/server
Then install.

Now, start leafpad:

Open ~/.bashrc (the ~ means it's in your home folder). You do that by clicking on File, Open, then click on file system, home, ecce, hit ctrl+H to show hidden files, and select .bashrc
Add the following to the end of the file:
export ECCE_HOME=/home/ecce/ecce-v6.3/apps
export PATH=$PATH:${ECCE_HOME}/scripts
alias startecceserver='/home/ecce/ecce-v6.3/server/ecce-admin/start_ecce_server'
alias stopecceserver='/home/ecce/ecce-v6.3/server/ecce-admin/stop_ecce_server'




Save, and exit leafpad.

Type
source ~/.bashrc
in your terminal. This will make the terminal read the new settings.
You still can't start since you're missing java:

So, in your terminal, do
sudo apt-get install default-jre

First make sure the ecce server isn't running
stopecceserver
then launch ecce
ecce
You're now being invited to set a new password:


Clicking OK launches what is called the Gateway:

7. Setting up ECCE
You're more than half-way there. The exact set up will depend on what you're trying to achieve and I've documented it elsewhere on this blog.

However, because I'm writing this guide with a couple of specific people in mind, I'll show how to set up a remote ROCKS site to submit to, using node hopping.

In the terminal, type
ecce -admin
 Set up as shown in the screen shot:

Don't forget to hit add/change queue first, then add/change in the bottom left, then close.

Because we're doing a lot of cool, advanced stuff we need to do some manual editing: we need to define the public url, and we need to define our SGE (Sun Grid Engine) settings and finally, we need to set up a couple of environment variables.

In the terminal, do
cd ~/ecce-v6.3/apps/siteconfig/
chmod u+rw CONFIG.rocks
Otherwise the file will be write-protected.


Using leafpad, open the CONFIG.rocks file which is found in /home/ecce/ecce-v6.3/apps/siteconfig/


Add the following (look at the screenshot below):
frontendMachine: rocks.university.edu

SGE {
#$ -S /bin/csh
#$ -cwd
#$ -l h_rt=$walltime
#$ -l h_vmem=$memoryG
#$ -j y
#$ -pe orte $totalprocs    
}

NWChemEnvironment{
            LD_LIBRARY_PATH /usr/lib/openmpi/1.3.2-gcc/lib/
}

NWChemCommand {
        /opt/openmpi/bin/mpirun -n $totalprocs $nwchem $infile > $outfile
}
Gaussian-03Command {
    setenv GAUSS_SCRDIR /tmp
    setenv GAUSS_EXEDIR /share/apps/gaussian/g09/bsd:/share/apps/gaussian/g09/local:/share/apps/gaussian/g09/extras:/share/apps/gaussian/g09
        time /share/apps/gaussian/g09/g09 $infile  $outfile }




Save and exit. (note the $memoryG so you don't put in 4000 but instead use 4 when setting memory during submission in launcher)

In the ECCE gateway, click on Machine Browser

Select rocks and click on Set Up Remote Access, give the user name and password. If all goes well, if you hit e.g. Disk Usage, you should see this:

8. Launching a test calc
Click on Organizer in the Gateway.






If you can't select basis set, theory etc. at this point, close the editor, then open again. Might be because it's the first run ever.


And launch:
 When it's done, it looks like this. Depending on your SGE set-up everything can be very fast, or every step can take a minute. To follow in real-time, click in Viewer. To see the output file, hit Run Mgmt and select tail -f. To look at output fiel from completed run, go to Run Mgmt and select Output.
It's fun, and easy!

9.  Moving files back and forth between your virtual debian and windows
First shut down your virtual machine, then click on settings.



When your virtual machine is running you can access it from e.g. windows using sftp with e.g. Filezilla like this:






I hope this guide has been useful. Again, it's long because of the level of detail, not because it's difficult in any way.

Learning how to use ECCE properly is a completely different tutorial. I might put up some examples with increasing complexity in the future.