195. Frequency calcs in NWChem

It's no secret that I'm a computational 'noob'. As such as I'm learning both by reading and by doing.

The doing part consists of checking 1) what the time penalty for different methods is and 2) what the accuracy/differences between different methods are.

Again, these are short calculations for simple molecules. Longer calculations with more exciting features (unpaired electrons, closely spaced MOs, highly negative charges etc.) may well behave completely different.

Today's focus is vibrational calcs.

Test Molecule: CHClF(OH) (chloro-fluoro-methanol)

  1 Title "Freq_test"
  2 
  3 Start  Freq_test
  4 
  5 echo
  6 
  7 charge 0
  8 
  9 geometry noautosym units angstrom
 10  C     0.0416942     -0.501783     0.399137
 11  H     0.0442651     -0.499048     1.48122
 12  O     1.21393     -1.00985     -0.0746688
 13  H     1.25125     -0.957351     -1.06923
 14  F     -1.08480     -1.08768     -0.134571
 15  Cl     -0.120345     1.41214     -0.0717951
 16 end
 17 
 18 ecce_print ecce.out
 19 
 20 basis "ao basis" cartesian print
 21   H library "3-21G"
 22   F library "3-21G"
 23   Cl library "3-21G"
 24   O library "3-21G"
 25   C library "3-21G"
 26 END
 27 
 28 dft
 29   mult 1
 30   odft
 31   mulliken
 32 end
 33 
 34 task dft energy
 35 task dft freq

All geometries were optimised in the gas phase using 3-21G.

0. Some useful statements:

hessian      print "hess_follow"
                 profile
end

1. Basis set (geometry optimised in 3-21g)
(time/enthalpy/entropy/scfe)
3-21G:              81s    24.984 kcal/mol    69.235 cal/mol-K   -671.17956992206 Hartree
6-31G:            105s    21.885 kcal/mol    68.793 cal/mol-K   -674.478768966106
6-31++G**:    399s   21.734 kcal/mol     68.818 cal/mol-K   -674.573524091623
cc-pVDZ:        325s    21.682 kcal/mol    68.819 cal/mol-K   -674.594059146606
aug-cc-pVDZ:  901s   21.605 kcal/mol    68.840 cal/mol-K   -674.623145113155

LANL2DZ(C)/6-+G* 262s  24.923 kcal/mol 68.981 cal/mol-K  -674.539040349134
UHF/aug-cc-pVDZ   373 s 26.196  kcal/mol 68.228 cal/mol-K -672.85402652170

Cation:
3-21G:               ---     21.164 kcal/mol     74.407 cal/mol-K    -670.763278724519 Hartree
6-31G:              142s   21.153 kcal/mol     74.645 cal/mol-K    -674.089132280731
6-31++G**:      637s   21.192 kcal/mol    73.768 cal/mol-K    -674.178146586266
cc-pVDZ:          399s   21.153 kcal/mol    73.736 cal/mol-K    -674.210312017948
aug-cc-pVDZ:   1776s 21.089 kcal/mol     73.774 cal/mol-K   -674.228204222891

LANL2DZ(C)/6-+G* 454s 24.795 kcal/mol  74.293 cal/mol-K -674.140922359750
UHF/aug-cc-pVDZ  741s 26.002 kcal/mol  72.462 cal/mol-K  -672.518095855130

2. Thermochemistry (ΔG of oxidation; gas phase)
3-21G:            -5.3620 kcal/mol +  261.22 kcal/mol =  6.814 V*
6-31G:            -2.4768 kcal/mol +  244.50 kcal/mol =  6.214 
6-31++G**:    -2.0178 kcal/mol+  248.10 kcal/mol =  6.390 
cc-pVDZ:        -1.9950 kcal/mol + 240.80 kcal/mol =  6.075 
aug-cc-pVDZ: -1.9871 kcal/mol + 247.83 kcal/mol =  6.380

LANL2DZ(C)/6-+G* -1.7118 kcal/mol + 249.82 kcal/mol = 6.478
UHF/aug-cc-pVDZ -1.4564 kcal/mol +210.80 kcal/mol = 4.797

* vs SHE=4.281 eV

3. Solvation (cosmo/water/scfe)
neutral
3-21g:                66s    22.097 kcal/mol    68.875 cal/mol-K   -671.1936338426 Hartree
6-31g:                82s    22.277 kcal/mol    68.609 cal/mol-K   -674.4934780299
6-31++g**:       277s   21.493 kcal/mol    69.353 cal/mol-K  -674.586704959695
cc-pVDZ:          266s   21.869 kcal/mol    68.808 cal/mol-K  -674.605608009070
aug-cc-pVDZ:    712s  22.116 kcal/mol    69.596 cal/mol-K   -674.635237990779

LANL2DZ(C)/6-31+G* 180s  25.022 kcal/mol   69.073 cal/mol-K -674.552417717602
UHF/aug-cc-pVDZ 412s  24.083 kcal/mol 70.519 cal/mol-K  -672.868085966222

cation (solvation energy)**

3-21G:               --- /26s        21.164 kcal/mol     74.407 cal/mol-K     -670.881469242560 Hartree
6-31G:              142s/51s      21.153 kcal/mol     74.645 cal/mol-K     -674.175491218588
6-31++G**:      637s/111s   21.192 kcal/mol    73.768 cal/mol-K      -674.267298880087
cc-pVDZ:          399s/129s   21.153 kcal/mol    73.736 cal/mol-K      -674.294609415029
aug-cc-pVDZ:   1776s/311s 21.089 kcal/mol     73.774 cal/mol-K     -674.316552324118

LANL2DZ(C)/6-31+G* 454s 24.795 kcal/mol  74.293 cal/mol-K -674.232656980139
UHF/aug-cc-pVDZ   741s 26.002 kcal/mol  72.462 cal/mol-K -672.451040948823
** UHF can't be used with COSMO according to nwchem. Instead we use the cation thermo calcs in the gas phase and use the scfe from a cosmo calc.

Thermochemistry*** (using gas phase freq for both cation and neutral species with scfe w/ cosmo given in parentheses):

3-21G:            -2.5824+195.88=  4.101 V (3.981 V)
6-31G:            -2.9236+199.54=  4.245 V (4.265 V)
6-31++G**:   -1.6173+200.43=  4.341 V (4.324 V)
cc-pVDZ:       -2.1853+195.15=  4.087 V (4.095 V)
aug-cc-pVDZ: -2.2727+199.98= 4.293 V (4.305 V)

LANL2DZ(C)/6-31+G*  -0.41322+200.65= 4.402
UHF/aug-cc-pVDZ 1.3397+261.7 (!)= 7.126
* vs SHE=4.281 eV

*** using freq calc of neutral species with cosmo, vs freq calc of cation in gas phase and energy w/ cosmo

4. Spectra
We'll use octave for this. First, using cat and gawk, I put the x/y coordinates in a file.

gauss= @(x,f,i,sigma)  i.*1./(sigma.*sqrt(2*pi)).*exp(-0.5.*((x-f)./sigma).**2)
subplot(3,2,1); axis([0 4000 0 2])
spc=load('321g.spc');sf=spc(:,1); si=spc(:,2);x=linspace(0,4000,800);spec=cumsum(gauss(x,sf,si,75)); 
title("321g"); plot(x,spec(18,:))
subplot(3,2,2)
spc=load('ccpvdz.spc');sf=spc(:,1); si=spc(:,2);x=linspace(0,4000,800);spec=cumsum(gauss(x,sf,si,75));
title("ccPVDZ");plot(x,spec(18,:))
subplot(3,2,3)
spc=load('631g.spc');sf=spc(:,1); si=spc(:,2);x=linspace(0,4000,800);spec=cumsum(gauss(x,sf,si,75));
title("631g"); plot(x,spec(18,:))
subplot(3,2,4)
spc=load('augccpvdz.spc');sf=spc(:,1); si=spc(:,2);x=linspace(0,4000,800);spec=cumsum(gauss(x,sf,si,75));
title("aug-ccPVDZ");plot(x,spec(18,:))
subplot(3,2,5)
spc=load('631gppdd.spc');sf=spc(:,1); si=spc(:,2);x=linspace(0,4000,800);spec=cumsum(gauss(x,sf,si,75));
title("631++g**"); plot(x,spec(18,:))

From top to bottom: Left: 3-21G, 6-31G, 6-31++G**. Right: cc-pVDZ, aug-cc-pVDZ

5. Conclusions
It may seem weird that as a test case I picked a species I don't have any reference potential for. However, the goal here was to understand how the basis set affects the results, without being distracted by such things as Real Life.

The observed spectra can be divided into two group: 3-21G/6-31G vs 6-31++G**/cc-pVDZ/aug-cc-pVDZ. Polarization (and diffuse functions) seem to play a large role.

In terms of thermochemistry, not surprisingly aug-cc-pVDZ and 6-31++G** give very similar results since they both implement pol/diff functions. The computational cost is, however, significantly higher for aug-cc-pVDZ than 6-31++G**, at least in nwchem.

There is also little difference between doing freq calculations in gas phase vs using cosmo when it comes to the calculated redox potential for the more extensive basis sets.

3-21G gives very varying results, with it giving the highest potential in the gas phase but the second lowest potential with cosmo. cc-pVDZ consistently gives the lowest potential.

UHF/ROHF/HF are fast, but wildly inaccurate. LANL2DZ/6-31+G* looks ok, results-wise, but the thermodynamic corrections are actually much smaller in conjunction with COSMO than the other methods, which is suspicious.

If given the time I may post a more detailed analysis of polarisation vs diffuse functions later.

194. Wine 1.4.1 and Wine 1.5.6 on Debian Wheezy

UPDATE 16 May 2013: See here for Wine 1.5.30: http://verahill.blogspot.com.au/2013/05/416-wine-1530-in-chroot.html

There's great appetite for anything wine-related in Debian, as I can see from visitor numbers, so  here's how to build  Wine 1.4.1 and Wine 1.5.6 in Debian Testing/Wheezy. Enough talking -- let's get compilin'!

The builds take a little while, so be warned. Not all features are enabled in this particular build either -- see the configure output.

If you're interested in the missing development files seen below, this post might help: http://verahill.blogspot.com.au/2012/03/cross-compiling-eg-32-bit-binaries-on.html. Instinctively, I am suspicious as to whether that would work. I haven't explored it though, and my chief motivation is to make build instructions which anyone can easily follow and reproduce.

UPDATE (10th Jan 2013): See here for Wine 1.5.21 using the multiarch approach: http://verahill.blogspot.com.au/2013/01/308-compiling-wine-1521-on-debian.html

For both
sudo apt-get install bison flex gcc libc6-dev libfontconfig-dev libfreetype6-dev libglu-dev libgsm1-dev libice-dev libjpeg-dev libldap-dev libmpg123-dev libncurses5-dev libopenal-dev libpng-dev libsm-dev libssl-dev libusb-dev libx11-dev libxcomposite-dev libxcursor-dev libxext-dev libxi-dev libxinerama-dev libxml2-dev libxrandr-dev libxrender-dev libxslt-dev libxt-dev libxxf86vm-dev make libcapi20-dev liblcms-dev libsane-dev libhal-dev libdbus-1-dev valgrind prelink libcups2-dev opencl-dev lib32opencl1 oss4-dev gettext lib32v4l-dev lib32ncurses5-dev lib32asound2-dev lib32z-dev ia32-libs-dev


Version 1.4.1

wget http://prdownloads.sourceforge.net/wine/wine-1.4.1.tar.bz2

tar xvf wine-1.4.1.tar.bz2
cd wine-1.4.1/
./configure

configure: OpenCL 32-bit development files not found, OpenCL won't be supported.
configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled
configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported.
configure: libtiff 32-bit development files not found, TIFF won't be supported.
configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported.
configure: Finished.  Do 'make' to compile Wine.

make
sudo checkinstall --install=yes

Note: To just make a .deb package, do ---install=no.

Version 1.5.6
wget http://prdownloads.sourceforge.net/wine/wine-1.5.6.tar.bz2
tar xvf wine-1.5.6.tar.bz2
cd wine-1.5.6/
./configure

configure: OpenCL 32-bit development files not found, OpenCL won't be supported.
configure: libsane 32-bit development files not found, scanners won't be supported.
configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled
configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported.
configure: libtiff 32-bit development files not found, TIFF won't be supported.
configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported.
configure: Finished.  Do 'make' to compile Wine.

make

sudo checkinstall --install=yes

Note: To just make a .deb package, do ---install=no.

193. Notes on UV/VIS - TD DFT in nwchem

I've been interested in looking at using NWChem to predict UV/VIS spectra. This post doesn't show how to do it but is rather just a look at what affects the positions of absorbances.

(although it more or less just involves
tddft
       cis
       nroots 24
end
task tddft energy)

I chose benzene and water as test cases. 

Here's water:

water

Reference spectrum in gas phase: http://www.lsbu.ac.uk/water/vibrat.html (166.5 nm) which tallies very well with 3-21g and 6-31g, but not at all with 6-31++g** or 3-21++g*.

Here's benzene:

Reference spectrum: http://www3.wooster.edu/chemistry/is/brubaker/uv/uv_spectrum.html
The reference spectrum, while a bit diffuse, shows the main absorbance at ca 178 nm. Presumably that's in benzene, not water.

More basis sets:

(cat Benzene_631g/Outputs/nwch.nwout |egrep "Root|sci"|gawk '{print $4,$6}'>bz631g.dat)

192. Skype on Debian STABLE (updated for Skype 4.x)

Update 15/6/12: New Skype (4) out this morning. Screengrabs etc posted at the end.

This post came about from a question posted on the Debian forums.

Before you read, be aware of this:

* I don't have debian 6.05 installed on any physical system. They all run debian wheezy

* This guide was done in a virtualbox installation. For sound, I used a headset and USB-passthrough. 

Having said that, there's no reason this shouldn't work.

As my system, I used the same one I used here (i.e. a very slim install):

http://verahill.blogspot.com.au/2012/06/ecce-in-virtual-machine-step-by-step.html

The advantage is that it's likely to a lot more barebones than a regular desktop debian install.

The disadvantage is that I don't know what's pulled in by default by debian 6.05.

Anyway, here's what I did:

1. Download and install  skype from skype.com

I selected the Debian 5 64 bit package which is gives you the skype-debian_2.2.0.35-1_amd64.deb file.

Install:

sudo dpkg -i skype-debian_2.2.0.35-1_amd64.deb 

Selecting previously deselected package skype.
(Reading database ... 53724 files and directories currently installed.)
Unpacking skype (from skype-debian_2.2.0.35-1_amd64.deb) ...
dpkg: dependency problems prevent configuration of skype:
 skype depends on lib32stdc++6 (>= 4.1.1-21); however:
  Package lib32stdc++6 is not installed.
 skype depends on lib32asound2 (>> 1.0.14); however:
  Package lib32asound2 is not installed.
 skype depends on ia32-libs; however:
  Package ia32-libs is not installed.
 skype depends on lib32gcc1 (>= 1:4.1.1-21+ia32.libs.1.19); however:
  Package lib32gcc1 is not installed.
 skype depends on ia32-libs-gtk; however:
  Package ia32-libs-gtk is not installed.
dpkg: error processing skype (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 skype

That's fine. Now fix the dependencies:

sudo apt-get install -f

Reading package lists... Done
Building dependency tree    
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  ia32-libs ia32-libs-gtk lib32asound2 lib32bz2-1.0 lib32gcc1 lib32ncurses5
  lib32stdc++6 lib32v4l-0 lib32z1 libv4l-0
Suggested packages:
  lib32asound2-plugins
The following NEW packages will be installed:
  ia32-libs ia32-libs-gtk lib32asound2 lib32bz2-1.0 lib32gcc1 lib32ncurses5
  lib32stdc++6 lib32v4l-0 lib32z1 libv4l-0
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 50.1 MB of archives.
After this operation, 123 MB of additional disk space will be used.
Do you want to continue [Y/n]? 

2. Get sounds organised

aptitude search pulseaudio|grep ^i

i A libpulse0                       - PulseAudio client libraries 

Not enough. Need. More. Packages.

sudo apt-get install pulseaudio pulseaudio-esound-compat pulseaudio-module-gconf

sudo apt-get install gnome-core

Obviously, if you have gnome installed, skip the second line.

Sort out your ~/.asoundrc file

echo "pcm.!default.type pulse">>~/.asoundrc

echo "ctl.!default.type pulse">>~/.asoundrc

At this point I rebooted for good luck.

3. Putting it all together

First open your volume control to see that it 'looks right'

Start Skype

Go to options (click on the S at the bottom left).  Make sure it says pulseaudio.

Make a test sound. Make a test call. Make sure to select the correct outputs and inputs in the gnome volume control

This worked perfectly for me and took all in all ca 25 minutes with screenshots and all.

Update 15/6/2012:
Skype 4 came out today -- I downloaded and installed it and tested it in the virtual machine above. Everything works perfectly.

---

Links to this post:
http://crunchbang.org/forums/viewtopic.php?id=27451

191. Thinking about Molecular volume -- and is cosmo/nwchem yielding the right ones?

Disclaimer:
I'm an neither a theoretical nor computational chemist. I'm an analytical/inorganic chemist who likes computers. Don't trust my conclusions. This is more like thinking aloud.

The problem:
The underlying impetus is that of molecular volume: if we have a set of scatter points in space which define the surface of a molecule, how can we extract the volume? In particular as we're actually given the surface points by in the form of a cosmo.xyz file by COSMO (and yes, nwchem also outputs a volume - more about that later) there's no reason why we won't do the calculations ourselves. Also, there's at least one example of comparing results from a few major software packages, where nwchem was the odd one out.

Because it's good to know how to use Octave and bash, I'll show the commands as well.

The COSMO parameters used were
cosmo
    rsolv 0
end

[come to think of it: why bother with
and nwchem returned

 atomic radii =
 --------------
    1  6.000  2.000
    2  6.000  2.000
    3  6.000  2.000
    4  6.000  2.000
    5  6.000  2.000
    6  6.000  2.000
    7  1.000  1.300
    8  1.000  1.300
    9  1.000  1.300
   10  1.000  1.300
   11  1.000  1.300
   12  1.000  1.300

and a volume of ca 74.5 ų

Processing:

me@Be:~$ head cosmo.xyz 

                  325
 cosmo charges
 Bq   2.1848085582473193      -0.38055253987610238        1.5251498369435705       -9.3089382062078174E-004
 Bq   1.6134835908159706      -0.59877925881345084        1.8782480854375714       -3.3706153046646758E-003
 Bq  0.43449121346899733      -0.59877925881345084        1.8782480854375714       -3.9739778624157118E-003
 Bq   1.0239874021424840      -0.23823332776127137        1.8683447179254316       -1.6433149723942275E-003

OK, we need to remove the first two lines, and the first column.

me@Be:~$ tail -n +3 cosmo.xyz|gawk '{print $2,$3,$4,$5}'> cos2.xyz

Start octave.

octave:1> bz=load('cos2.xyz');
octave:2> x=bz(:,1);y=bz(:,2);z=bz(:,3);c=bz(:,4);
octave:3> plot3(x,y,z)

Paradoxically, this would be fairly easy to do with a 'normal-size' physical object (e.g. water displacement, or area on a 2D project: draw it, cut it out, weigh it and use the density of the paper)

 Computationally, we need to think about it though. The most logical approach seems to be to take all x,y data points with a small range of values of z=z_i±dz, project them on a 2D surface, calculate the area within, and multiply it by dz. Do this for all values of z.

octave:4> plot(y,z,'*')

But how to calculate the area inside an arbitrary two-dimensional figure then? If we can pick a point in the 'centre' of the figure, we can draw repeated triangles with this point as one of the corners. It's easy to calculate the area of a triangle, so we just need to sum the areas of the triangles. All we need to know is how to find such a central point to use as a corner. Also, there are problems when dz is too large and the 'border' becomes fuzzy.

octave:5> plot(y(1:25),z(1:25),'*')

In fact, at this stage there may well be pre-canned algorithms to help us.

octave:6>H=convhull(y(1:25),z(1:25));
octave:7>plot(y(H),z(H))
octave:8>hold
octave:9>plot(y(1:25),z(1:25),'*')

That way we can reduce the number of points to the ones defining the encircling figure.

octave:10>area(y(H),z(H))

That still doesn't give us the area (I think matlab does though). Since it's centred around the x axis we could probably use cumsum(abs(z(H))), but that's not general enough. In fact, there'd be so much  quality analysis required in order to make sure that we include enough, but not too many, points in our slices that it quickly becomes a chore.

So we'll take a step back. Turns out it's even easier:

octave:11>[H V]=convhulln([x y z]);

This probably isn't how you're supposed to plot it, but it works:

octave:13>trisurf(H,x,y,z)

trisurf plot

octave:12>V

gives V=104.07  Å³ (c.f. Nwchem/cosmo ca 74.5 ų for rsolv=0.)

Now that doesn't look good, but it has been noted nwchem/cosmo gives volumes which are about half of what every other program gives. See here and here:

">Cosmo produced volumes, which were twice as small
> as those obtained by PCM, while surfaces where by about 15% bigger in
> Cosmo."

I think nwchem actually isn't returning values of the wrong magnitude -- I think the value returned by nwchem is the molecular volume, while the other programmes return the solvent accessible surface-based volume. But what is in cosmo.xyz?

It appears to be a little bit more complex than that though.

---

We can open the cosmo.xyz file in jmol, but calculating the volume from these would be meaningless due to the way jmol works.

Instead we'll have to use the VdW radii of the xyz coordinates of the (unoptimised) molecule:

$ isosurface sasurface 0.5 volume
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceVolume = 141.06999
$ isosurface sasurface 0.225 volume
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceVolume =104.452415
$ isosurface solvent 0 volume
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceVolume = 79.09731
$ isosurface solvent volume
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceVolume = [80.26721490808025]
$ isosurface molecular volume
isosurface2 created with cutoff=0.0; isosurface count: 2
isosurfaceVolume = [80.58888982478977]
$ isosurface sasurface 0.2 area
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceArea = 118.730934

Making sense?

sasurface generates a solvent accessible surface. We can generate a value similar to what we saw from the cosmo.xyz points by forcing the sasurface probe radius..

The vdw radii of H and C are 1.2 and 1.7 Å, but COSMO uses 1.3 and 2.0.

Look at this plot again:

The height goes from -2 to 2, which agrees with the large 2.0 Å VDW radius for C that COSMO uses. The volume outputted by Nwchem is the molecular volume (as actually is stated). 

 number of -cosmo- surface points =      176
 molecular surface =    125.008 angstrom**2
 molecular volume  =     74.512 angstrom**3
(electrostatic) solvation energy =         0.0052128678 (    3.27 kcal/mol)

The molecular volume for rsolv=0 is 74.5 Å³ which is fairly close to isosurface sasurface 0 volume. Area is trickier, and requires isosurface sasurface 0.23 volume to yield anything close.

I don't think it's a coincidence that isosurface sasurface 0.225 volume gives a reasonable agreement with the cosmo.xyz, since 1.7+0.225=1.925 which is ca 2 (we only add 0.1 for H).

I'm sure all this is in the manual somewhere. But there's nothing like learning through doing.

The conclusions:
* NWchem returns a volume based on the vdw radii, not the solvent cavity
* cosmo.xyz contains points defining the surface according to the vdw radii that cosmo uses
* These are two different sets of vdw radii
* You can't compare the output of different software packages if they aren't outputting the same data
* The reported NWChem volume does depend on rsolv, the cosmo vol doesn't
* The cosmo.xyz volume is insensitive to rsolv, but sensitive to radius as expected. As far as I understand, the cosmo volumes are based solely on the vdw radii (as supplied to cosmo)
* I haven't quite figured out how, but looking at the dependency of rsolve vs defining vdw radii for cosmo, the radii used to calculate the nwchem volume is is certainly affected.

Increase rsolv=0.0, increase vdw +0.0: 74.51/104.07/3.27
Increase rsolv=0.5, increase vdw +0.0: 58.0/103.96/3.01
Increase rsolv=1.0, increase vdw +0.0: 54 /103.87/2.95
Increase rsolv=0.0, increase vdw +0.1: 84.79/115.10/2.72
Increase rsolv=0.1, increase vdw +0.1: 82.68/115.10/2.63
Increase rsolv=0.27, increase vdw +0.1: 71.84/114.97/2.56
Increase rsolv=0.0, increase vdw +0.2: 96.59/126.83/2.22
Increase rsolv=0.1, increase vdw +0.2: 85.70/126.68/2.09
increase rsolv=0.70, increase vdw +0.2: 74.68/126.56/2.01

My only real conclusion at this point is that you have to be extremely careful about what you do. This is not easy.

---

A Certain Commercial Programme (ACCP):

Using pcm:

scrf=(pcm,solvent=water) -- this uses vdw radii.

GePol: Cavity volume                                =      134.665 Ang**3
GePol: Cavity surface area                          =    143.132 Ang**2

Let's see if we can do this in jmol:

$ isosurface sasurface 0.5 area
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceArea = 144.25595
$ isosurface sasurface 0.46 volume
isosurface1 created with cutoff=0.0; isosurface count: 1
isosurfaceVolume = 135.33589

PCM is less of a mystery now.

ACCP has a few more options though.
Using IPCM with 50 points. This uses the isodensity volume.

Volume of Solute Cavity = 8.026500E+02
Total "Solvent Accessible Surface Area" of Solute = 4.485628E+02

I've been told that the units are in Bohr³ and Bohr². That translates to 118.94 ų and 125.61ų, respectively, which sounds about right. 

190. In deep water: NWChem and COSMO

This post is based entirely on empirical experience. I don't claim to know what I'm doing. Right now I'm just looking at performance.

To actually learn more about COSMO (implemented) and COSMO-RS (not implemented), read the following article by the creator of the methods: http://onlinelibrary.wiley.com/doi/10.1002/wcms.56/abstract

Anyway.

---

As always, the test job (benzene at b3lyp/g-31+g*) is very short, so the error margin is large. A major impetus for this is the execeptional performance of PCM in gaussian, and seemingly poor performance of nwchem using standard settings. When several numbers are quoted they come from multiple runs

Task energy - empty COSMO block:
0. Gas phase - ca 40 s
1. From scratch. Empty cosmo block - 79 s
2. Loaded movecs from gas phase, empty cosmo block - 48 s, 65 s, 65 s

The default is water and rsolv=0

COSMO parameters
Movecs loaded in all cases. Solvation energies in []

Task energy -- rsolv
0. rsolv=0 - [3.27 kcal/mol] - 48 s, 65 s, 65 s, 65 s
1. rsolv=0.5 - [3.01 kcal/mol] - 58 s, 58 s
2. rsolv=1 - [2.95 kcal/mol] - 57 s, 57 s, 58 s
3. rsolv=2 - [2.62 kcal/mol] - 55 s

The molecular volumes obtained are 74.5, 58.0 and 54.0 Å3, respectively, for r=0..1. My next post will talk about what this actually means, but in short, this has nothing to do with the solvent/solute cavity.

Task energy -- lineq
0. rsolv=0.5; lineq 0 - [3.01 kcal/mol] - 58 s, 58 s, 56 s
1. rsolv=0.5; lineq 1 - [3.01 kcal/mol] -  58 s

Task energy -- ificos
0. rsolv=0.5; lineq 0, ificos=0 - [3.01 kcal/mol] - 58 s, 58 s, 56 s
1. rsolv=0.5; lineq 0, ificos=1 - [3.01 kcal/mol] - 62 s

1 (one) kcal./mol = 4.184 kJ/mol -- there's thus a fairly wide range of values obtained above depending on the absolute settings.

Rsolve defines the probe used to find the solvent accessible surface -- the smaller the value, the more fine-grained and larger the apparent accessible surface. We would expect that a fairly small number is preferable for rsolv.

Ultimately, I don't see any obvious way of improving performance, other than using large values for rsolv.

---

An interesting feature is that the surface used by COSMO is save in a cosmo.xyz file in the runtime directory -- all that remains is working out a way of calculating the volume from this (I know it's reported in the nwchem output, but it never hurts being paranoid)

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.

188. Notes: virtualbox and /etc/init.d/vboxdrv

If you install virtualbox and get ready to fire up the installation of a new virtual machine, but immediately get an error about having to do '/etc/init.d/vboxdrv setup' -- but find that there's no such executable in /etc/init.d in spite of having installed the virtualbox-dkms package, then

sudo apt-get install linux-headers-`uname -r`
sudo dpkg-reconfigure virtualbox-dkms

187. Thunderbird 13.0 from source on debian wheezy

First look here for dependencies:
http://verahill.blogspot.com.au/2012/05/thunderbird-1201-on-debian.html

In terms of building it's almost exactly the same as for the 12-series: the only difference is that you have to build outside the source tree.

cd ~/tmp
rm comm-release -rf
wget ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/13.0/source/thunderbird-13.0.source.tar.bz2
tar xvf thunderbird-13.0.source.tar.bz2
mkdir thunderbird13
cd thunderbird13
../comm-release/./configure --disable-necko-wifi

The next step takes a while (30-60 minutes)
make 

sudo make install

Done.

What's new: http://www.ghacks.net/2012/06/06/whats-new-in-thunderbird-13/

---

Errors
No rule to make target ../../../xpcom/idl-parser/xpidllex.py
Solution:

Build outside the source tree as shown above.

186. Installing gnome shell extensions in gnome 3.4 on debian wheezy-- frippery panel, menu etc.

Gnome 3.4 frippery extensions in Debian Wheezy: bottom panel, favourites etc.
Upgrading to gnome 3.4 disabled all my extensions. It also remove all my keyboard shortcuts.

Update: Interesting take on ther GNOME 3/KDE 4releases  http://www.datamation.com/open-source/the-gnome-exodus-and-kde-2.html I think the idea of a lack of trust is a valid one: I might be able to get GNOME to do what I want today, but whatabout tomorrow? How much longer can I manually patch my screenshot app?

So, we need to get:
* move clock
* favourites
* application menu
* bottom panel
* static workspaces

Btw, extensions.gnome.org doesn't do International English. Try searching for favourites. And that's just the beginning of the headaches. I had problems finding any extensions compatible with gnome 3.4.

Anyway, as usual frippery (http://intgat.tigress.co.uk/rmy/extensions/index.html) comes to the rescue of the users (and by extension to the rescue of Gnome -- I'd already be long gone if I couldn't revert some of the more insane behaviour of gnome-shell...)

In your ~ folder (in order that the files get untared to the correct location)
wget http://intgat.tigress.co.uk/rmy/extensions/gnome-shell-frippery-0.4.1.tgz
tar xvf gnome-shell-frippery-0.4.1.tgz 

Hit alt+f2 to bring up the launcher thingy, type 'r' and hit enter. You're done!

To make life worth living again, also do
sudo apt-get install gnome-tweak-tool
if you haven't already

That way you can get the Minimize/Maximize/Close buttons back on your window border.

Another noticeable change is that it's become very difficult to resize windows using the mouse -- expand horizontally or vertically is like before, but dragging a corner is tough -- it takes a lot of fiddling to be able to grab the corner in the first place.

Finally, ctrl+b is mapped to some bookmark function in epiphany/web which is annoying, since it's universally used to make things bold. The gnome developer instructions even say not to do this:
http://developer.gnome.org/hig-book/3.4/input-keyboard.html.en （see table 10.8)

---

Interesting side-effect:
my fancy gnome-screenshot.debugged isn't called anymore -- and the metacity/keybinding_commands list is depopulated in addition to the gnome system settings/keyboard/shortcuts/Custom. Gnome shell 3.4 seems to mark the point where gconf-editor is deprecated. See the gnome-screenshot compilation post for more info.

At any rate, the keyboard shortcuts related to Screenshots now contains five different combination commands. Seriously -- they 'simplify' gnome-screenshot, then they want users to learn four different key combinations in addition to vanilla prtscr? And none of them does what I really need -- i.e. a quick and simple way to save screenshot with the name I want in the location I want.

---

Links to this post:
https://www.linuxquestions.org/questions/debian-26/how-to-add-panel-in-gnome-debian-wheezy-4175463451/

185. Troubleshooting: ECCE

184. Fixing Gnome screenshot (3.4.1) in Debian Wheezy by patching and compiling

Approach
Putting a hold on gnome-screenshot forever will likely prevent gnome from upgrading properly since I'd suspect it's a required dependency.

Clarification: this fix restores the original behaviour. gnome-screenshot --interactive is NOT an acceptable solution. This guide restores gnome-screenshot to it's good old functional state.

So, time to build our own gnome-screenshot -- but one which actually works in a reasonable way. The gnome-screenshot cockup is just another sign that something is clearly amiss with the way gnome is being developed. And this, if true, is another truly idiotic 'feature' -- turn gnome into windows? Most of us left for a reason...

Anyway, linux is still sane though -- if we don't like something we're not entirely up a creek, which will buy us a bit more time while we're getting ready to move to xmonad  -- or for debian to move away from not making downstreams changes to gnome.

We have two options:
Either look here: http://git.gnome.org/browse/gnome-screenshot/commit/?id=3bbc1e158fd58ec7f4f984f6d3c15ec95e65a035&ignorews=1 and try to come up with your own way of reverting the crippling.

Or use the ubuntu patches as a guide: http://packages.ubuntu.com/precise/gnome-screenshot

Normally you shouldn't mix ubuntu and debian packages, and we won't: we'll be compiling our own package, but using the work done by the ubuntu maintainers.

In particular, look at this: http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-screenshot/gnome-screenshot_3.4.1-0ubuntu1.debian.tar.gz

Look in the debian/patches directory and you'll find the ubuntu_interative_screenshots.patch

Building:
sudo apt-get install libgtk-3-dev libcanberra-gtk3-dev intltool
wget http://ftp.de.debian.org/debian/pool/main/g/gnome-screenshot/gnome-screenshot_3.4.1.orig.tar.xz
tar xvf gnome-screenshot_3.4.1.orig.tar.xz
cd gnome-screenshot-3.4.1/src

You can wget http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-screenshot/gnome-screenshot_3.4.1-0ubuntu1.debian.tar.gz and untar it to look at the debian/patches/ubuntu_interactive_screenshots.patch, which what we do below is based on:

In the ubuntu patch there's a test to see whether unity is used. We'll do it a bit cruder -- we'll just make sure the condition is always true by testing for 0<1.

Edit src/screenshot-application.c and change the part in red

130 static void

131 save_pixbuf_handle_error (ScreenshotApplication *self,

132                           GError *error)

133 {

134   if (screenshot_config->interactive)

135     {

136       ScreenshotDialog *dialog = self->priv->dialog;

137       GtkWidget *toplevel = screenshot_dialog_get_toplevel (dialog);

138 

139       screenshot_dialog_set_busy (dialog, FALSE);

to

134   if (0 < 1)

Also, change

348   screenshot_play_sound_effect ("screen-capture", _("Screenshot taken"));

349 

350   if (screenshot_config->interactive)

351     {

352       self->priv->dialog = screenshot_dialog_new (self->priv->screenshot, self->priv->save_uri);

353       toplevel = screenshot_dialog_get_toplevel (self->priv->dialog);

354       gtk_widget_show (toplevel);

to

350   if (0 < 1 )

Time to build!
./configure --prefix=${HOME}/.gsc --program-suffix=.debugged
make
make install

Note: the install prefix here works fine for a single-user desktop. If you want everyone to be able to use our shiny new gnome-screenshot, put everything in /usr/bin instead.

We now have a working gnome screenshot in ~/.gsc that behaves as intended.
tree -L 2 -d
.
|-- bin
`-- share
    |-- applications
    |-- GConf
    |-- glib-2.0
    |-- gnome-screenshot
    |-- locale
    `-- man

---

 However, we need to make sure our fixed gnome-screenshot gets invoked.

In Gnome Shell 3.2.X
sudo apt-get install gconf-editor
Start gconf-editor
go to /apps/metacity/keybinding_commands/command_screenshot
change to e.g.  /home/verahill/.gsc/bin/gnome-screenshot.debugged
Also, change command_window_screenshot to
/home/verahill/.gsc/bin/gnome-screenshot.debugged --window

Note: defining Print/Alt+print keyboard shortcuts the 'gnome-shell' way (i.e. via system-settings) doesn't seem to work in gnome 3.2. Conversely, doing it the gconf-editor way in gnome 3.4 doesn't work.


In Gnome Shell 3.4.X
Go to System Settings, Keyboard, Shortcuts
Disable the automatically defined shortcuts for gnome-screenshot

And add your own under custom shortcuts:

Done! 
Unless you want to add to PATH in which case you can put this in your ~/.bashrc:
export PATH=$PATH:${HOME}/.gsc/bin

---

Note: If it's still not working, try to launch from the terminal. If you get

(gnome-screenshot.debugged:7493): GLib-GIO-ERROR **: Settings schema 'org.gnome.gnome-screenshot' does not contain a key named 'auto-save-directory'
Trace/breakpoint trap

it's because you had the old, good gnome-screenshot. 

sudo su

echo "gnome-screenshot install"|dpkg --set-selections

exit

sudo apt-get install gnome-screenshot

Now try

gsettings get org.gnome.gnome-screenshot auto-save-directory
which should be empty.

gsettings set org.gnome.gnome-screenshot auto-save-directory '/home/verahill/Pictures'

Finally, make sure to re-set your keybindings.

---

Links to this post:
http://qfox.nl/notes/153

183. Compiling OpenMM 4.1 on debian testing

OpenMM 4.0 is still somewhat of a traumatic memory. However, having gotten a question about the compilation of v4.1 I can't really resist giving the new version a go.

Having said that, I never ended up using the GPU-enabled gromacs for which I built openmm, so it was all an enormous waste of time -- for those of you thinking about GPU/Gromacs know this:
* not all graphics cards are supported or worth supporting
* there's no speed-up for explicit solvent molecules, and what else would you use gromacs or MD for?
* consumer-grade graphics cards get very hot

I make no attempt at ferreting out what packages are needed other than what I'm explicitly prompted for. Look at http://verahill.blogspot.com.au/2012/01/debian-testing-64-wheezy_20.html for an indication of what you might need.

Also, I already have openmm 4.0 installed, so e.g. paths and other things defined in the post above are still active.

---

Start here
Register with simtk.org and download the source file.
sudo apt-get install cmake-curses-gui libgccxml-dev gccxml nvidia-cuda-toolkit
unzip -x OpenMM4.1-Source.zipe
mkdir openmm_build
cd openmm_build/
ccmake -i ../OpenMM4.1-Source/

It'll say Empty Cache. Hit c which will populate the list.

I think we can ignore the EMU libs since they do device emulation. I never figured out what the CUT program was and it's not mentioned in the manual from what I can see.

These are the settings I chose -- I had problems before setting the OPENCL parts (in red) to off.

BUILD_TESTING:BOOL=ON
CMAKE_BUILD_TYPE:STRING=Release
CMAKE_INSTALL_PREFIX:PATH=/home/verahill/.openmm
CUDA_BUILD_TYPE:STRING=Device
CUDA_INSTALL_PREFIX:PATH=/usr/bin
CUDA_NVCC:FILEPATH=/usr/bin/nvcc
DL_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libdl.so
FOUND_CUBLAS:FILEPATH=/usr/lib/x86_64-linux-gnu/libcublas.so
FOUND_CUBLASEMU:FILEPATH=FOUND_CUBLASEMU-NOTFOUND
FOUND_CUFFT:FILEPATH=/usr/lib/x86_64-linux-gnu/libcufft.so
FOUND_CUFFTEMU:FILEPATH=FOUND_CUFFTEMU-NOTFOUND
FOUND_CUT:FILEPATH=FOUND_CUT-NOTFOUND
FOUND_CUT_INCLUDE:PATH=FOUND_CUT_INCLUDE-NOTFOUND
GCCXML_EXTRA_ARGS:STRING=
GCCXML_PATH:FILEPATH=/usr/bin/gccxml
OPENMM_BUILD_AMOEBA_CUDA_LIB:BOOL=ON
OPENMM_BUILD_AMOEBA_PLUGIN:BOOL=ON
OPENMM_BUILD_CUDA_LIB:BOOL=ON
OPENMM_BUILD_CUDA_TESTS:BOOL=TRUE
OPENMM_BUILD_C_AND_FORTRAN_WRAPPERS:BOOL=ON
OPENMM_BUILD_FREE_ENERGY_CUDA_LIB:BOOL=ON
OPENMM_BUILD_FREE_ENERGY_PLUGIN:BOOL=ON
OPENMM_BUILD_OPENCL_LIB:BOOL=OFF
OPENMM_BUILD_OPENCL_TESTS:BOOL=OFF
OPENMM_BUILD_PYTHON_WRAPPERS:BOOL=ON
OPENMM_BUILD_RPMD_OPENCL_LIB:BOOL=OFF
OPENMM_BUILD_RPMD_PLUGIN:BOOL=ON
OPENMM_BUILD_SERIALIZATION_SUPPORT:BOOL=ON
OPENMM_BUILD_STATIC_LIB:BOOL=ON
OPENMM_GENERATE_API_DOCS:BOOL=OFF
OPENMM_SVN_REVISION:STRING=exported
PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python
SVNVERSION_PROGRAM:FILEPATH=/usr/bin/svnversion
SWIG_EXECUTABLE:FILEPATH=/usr/bin/swig
SWIG_VERSION:STRING=2.0.7

Make your changes and hit c again, then hit g which brings you back to the terminal.

make -d|tee make.log
make test


If all goes well you'll see

126/126 Test #126: TestParser ......................................   Passed    0.02 sec
100% tests passed, 0 tests failed out of 126
Total Test time (real) = 345.83 sec

make install

[..]
-- Installing: /home/verahill/.openmm/examples/Makefile
-- Installing: /home/verahill/.openmm/examples/NMakefile
-- Installing: /home/verahill/.openmm/examples/MakefileNotes.txt
-- Installing: /home/verahill/.openmm/examples/Empty.cpp

And you are done!

tree ~/.openmm/ -L 4 -d

.openmm/

|-- bin

|-- docs

|   |-- api-c++

|   `-- api-python

|-- examples

|   `-- VisualStudio

|-- include

|   `-- openmm

|       |-- internal

|       `-- serialization

|-- lib

|   `-- plugins

`-- licenses

182. Oracle Java JDK (java, javac and javaws) in debian testing/wheezy

With ECCE I was having problems with getting the same version of java and javac on a computer where I was using sun java 6.0

Since I'm using SGE I (think I) need the closed source SUN java version.
Download (and click on the license agreement) here:
http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u32-downloads-1594644.html


(v7u4 is available here:
http://www.oracle.com/technetwork/java/javase/downloads/jdk-7u4-downloads-1591156.html
)

Then follow this: http://verahill.blogspot.com.au/2012/04/installing-sunoracle-java-in-debian.html
sudo apt-get install java-package
make-jpkg jdk-6u32-linux-x64.bin

and follow the instructions. Once the package is built, install:
sudo dpkg -i oracle-j2sdk1.6_1.6.0+update32_amd64.deb

Unpacking oracle-j2sdk1.6 (from oracle-j2sdk1.6_1.6.0+update32_amd64.deb) ...
Setting up oracle-j2sdk1.6 (1.6.0+update32) ...
update-alternatives: using /usr/lib/jvm/j2sdk1.6-oracle/jre/bin/ControlPanel to provide /usr/bin/ControlPanel (ControlPanel) in auto mode.
update-alternatives: using /usr/lib/jvm/j2sdk1.6-oracle/jre/lib/amd64/libnpjp2.so to provide /usr/lib/iceweasel/plugins/libjavaplugin.so (iceweasel-javaplugin.so) in auto mode.
update-alternatives: using /usr/lib/jvm/j2sdk1.6-oracle/jre/lib/amd64/libnpjp2.so to provide /usr/lib/chromium/plugins/libjavaplugin.so (chromium-javaplugin.so) in auto mode.

sudo update-alternatives --config java

There are 6 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/lib/jvm/j2re1.6-oracle/bin/java             314       manual mode
  4            /usr/lib/jvm/j2sdk1.6-oracle/jre/bin/java        315       manual mode
  5            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      manual mode
  6            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1051      manual mode

sudo update-alternatives --config javac

There are 2 choices for the alternative javac (providing /usr/bin/javac).
  Selection    Path                                         Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-7-openjdk-amd64/bin/javac   1051      auto mode
  1            /usr/lib/jvm/j2sdk1.6-oracle/bin/javac        315       manual mode
  2            /usr/lib/jvm/java-7-openjdk-amd64/bin/javac   1051      manual mode

sudo update-alternatives --config javaws

There are 3 choices for the alternative javaws (providing /usr/bin/javaws).

  Selection    Path                                              Priority   Status

------------------------------------------------------------

  0            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/javaws   1061      auto mode

* 1            /usr/lib/jvm/j2re1.6-oracle/bin/javaws             314       manual mode

  2            /usr/lib/jvm/j2sdk1.6-oracle/jre/bin/javaws        315       manual mode

  3            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/javaws   1061      manual mode

While I was making the package this little guy popped up. Don't fret. I think it was meant to take me to the java.com website or something similar. I don't like the sight of that /root/ thingy though -- what's oracle thinking of us punters?

181. Compiling openmpi on debian wheezy

There's nothing complicated about this compilation. It's not a terribly quick build though, and I'm not yet sure exactly what packages are necessary.

sudo apt-get install build-essential gfortran
wget http://www.open-mpi.org/software/ompi/v1.6/downloads/openmpi-1.6.tar.bz2
tar xvf openmpi-1.6.tar.bz2
cd openmpi-1.6/

sudo mkdir /opt/openmpi/
sudo chown ${USER} /opt/openmpi/

./configure --prefix=/opt/openmpi/1.6/ --with-sge

make
make install

And you're done.

tree -L2 -d /opt/openmpi

Linking to the libs is done as before, although the path to e.g. libmpi.so is /opt/openmpi/1.6/lib/ and not /opt/openmpi/1.6/lib/openmpi/ like in the regular debian package.

.

└── 1.6

    ├── bin

    ├── etc

    ├── include

    │   ├── openmpi

    │   └── vampirtrace

    ├── lib

    │   ├── openmpi

    │   └── pkgconfig

    └── share

        ├── man

        ├── openmpi

        └── vampirtrace

You might also want to update the /etc/alternatives/libmpi.so symlink.

This is definitely one of those packages where it's worth doing ./configure --help to see what options are available.

Also, I imagine that on ROCKS there may well be a few packages which will have to be compile first and specified using --with-<> switches.

A sample:

  --with-blcr(=DIR)       Path to BLCR Installation
  --with-blcr-libdir=DIR  Search for BLCR libraries in DIR
  --with-hwloc(=DIR)      Build hwloc support. DIR can take one of three
  --with-hwloc-libdir=DIR Search for hwloc libraries in DIR. Should only be
  --with-valgrind(=DIR)   Directory where the valgrind software is installed
  --with-memory-manager=TYPE
  --with-libpicl(=DIR)    Build libpicl support, optionally adding
  --with-libpicl-libdir=DIR
  --with-timer=TYPE       Build high resolution timer component TYPE
  --with-portals=DIR      Specify the installation directory of PORTALS
  --with-portals-libs=LIBS
                          Libraries to link with for portals
  --with-alps             Build ALPS scheduler component (default: no)
  --with-lsf(=DIR)        Build LSF support
  --with-lsf-libdir=DIR   Search for LSF libraries in DIR
  --with-pmi              Build PMI support (default: no)
  --with-cray-pmi-ext     Include Cray PMI2 extensions (default: no)
  --with-slurm            Build SLURM scheduler component (default: yes)
  --with-tm(=DIR)         Build TM (Torque, PBSPro, and compatible) support,
  --with-ftb(=DIR)        Build FTB (Fault Tolerance Backplane) support,
  --with-ftb-libdir=DIR   Search for FTB (Fault Tolerance Backplane) libraries
  --with-esmtp(=DIR)      Build esmtp support, optionally adding DIR/include,
  --with-esmtp-libdir=DIR Search for the esmtp libraries in DIR
  --with-sge              Build SGE or Grid Engine support (default: no)
  --with-loadleveler      Build LoadLeveler scheduler component (default: yes)
  --with-elan(=DIR)       Build Elan (QsNet2) support, searching for libraries
  --with-elan-libdir=DIR  Search for Elan (QsNet2) libraries in DIR
  --with-mx(=DIR)         Build MX (Myrinet Express) support, optionally
  --with-mx-libdir=DIR    Search for MX (Myrinet Express) libraries in DIR
  --with-openib(=DIR)     Build OpenFabrics support, optionally adding
  --with-openib-libdir=DIR
  --with-portals(=DIR)    Build Portals support, optionally adding
  --with-portals-config   configuration to use for Portals support. One of
  --with-portals-libs=LIBS
                          Libraries to link with for portals
  --with-sctp(=DIR)       Build SCTP support, searching for libraries in DIR
  --with-sctp-libdir=DIR  Search for SCTP libraries in DIR
  --with-knem(=DIR)       Build knem Linux kernel module support, searching
  --with-udapl(=DIR)      Build uDAPL support, optionally adding DIR/include,
  --with-udapl-libdir=DIR Search for uDAPL libraries in DIR
  --with-fca(=DIR)        Build fca (Mellanox Fabric Collective Accelerator)
  --with-io-romio-flags=FLAGS
  --with-mxm(=DIR)        Build Mellanox Messaging support
  --with-mxm-libdir=DIR   Search for Mellanox Messaging libraries in DIR
  --with-psm(=DIR)        Build PSM (Qlogic InfiniPath) support, optionally
  --with-psm-libdir=DIR   Search for PSM (QLogic InfiniPath PSM) libraries in
  --with-contrib-vt-flags=FLAGS
  --with-event-rtsig      compile with support for real time signals
  --with-pic[=PKGS]       try to use only PIC/non-PIC objects [default=use
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
  --with-sysroot=DIR Search for dependent libraries within DIR

180. Temporary fix for supertuxkart

I don't often play games, but I noticed that supertuxkart had been updated in debian wheezy and having a little bit of free time I figured I'd give it a whirl.

 supertuxkart 

supertuxkart: error while loading shared libraries: libIrrlicht.so.1.7a.3: cannot open shared object file: No such file or directory

Make sure that libirrlicht1.7a is installed.

sudo apt-get install libirrlicht1.7a

Then

cd /usr/lib

sudo ln -s libIrrlicht.so.1.7a.2 libIrrlicht.so.1.7a.3

It's obviously not a permanent fix, but I haven't had any problems playing.

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.

178. Gridengine queues on heterogeneous systems

I don't want to risk three slot jobs being submitted to quad core jobs, so I figured I'll try setting up different queues based on the jobs parameters.

Some reading:
http://wiki.gridengine.info/wiki/index.php/StephansBlog
https://www.clumeq.ca/wiki/index.php/Using_SGE#Queues_List
http://ait.web.psi.ch/services/linux/hpc/merlin3/sge/admin/sge_queues.html

qconf -ahgrp @quads

group_name @quads
hostlist tantalum

qconf -aq four.q

qname                  three.q
hostlist              @quads
seq_no             1
slots                 4,[tantalum=4]
pe_list              make mpi4

qconf -ahgrp @thrice

group_name @thrice
hostlist boron beryllium

qconf -aq three.q

qname                 three.q
hostlist              @thrice
seq_no                1
pe_list               make mpi3
slots                 3,[boron=3],[beryllium=3]

Finally, to avoid submitting jobs to main.q without deleting it, we change the seq_no to 9 for that particular q.
Also, we'll change the pe_list on main.q to remove mpi3 and mpi4 -- that way main.q is only used if I request only one core.

pe_list       make mpi1

And now jobs get sent to the right queue (and node) depending on the number of cores I request.