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

14 February 2018

647. Linda/G16 and ecce + slurm

I had the opportunity to test G16 with Linda on my cluster. Suprisingly, I observed a decent reduction in computational time for geometry optimisation, and a fair reduction for vibrational analysis.

Computational time -- geometry optimisation
1x6 cores: 100%
2x6 cores: 56% (2 nodes)
3x6 cores: 44% (3 nodes)

Computational time -- normal mode computation
1x6 cores: 100%
2x6 cores: 63% (2 nodes)
3x6 cores: 57% (3 nodes)

In no case was the speed up good enough that it actually makes long-term sense to use Linda (need less than 50% for 2 nodes and 33% or less for 3 nodes), but if you're itching for quick results, it might be worth it.

Either way, as part of this I wrote a CONFIG.Linda for ECCE and SLURM:
Gaussian-16: /opt/gaussian/g16a/g16/g16 perlPath: /usr/bin/ qmgrPath: /usr/bin/ xappsPath: /usr/bin/ Slurm { #!/bin/csh #SBATCH -p linda #SBATCH --time=$walltime #SBATCH --output=slurm.out #SBATCH --job-name=$submitFile #SBATCH --nodes=$nodes #SBATCH --cpus-per-task=$ppn } Gaussian-16FilesToRemove{ core } Gaussian-16Command{ set path = ( /opt/nbo6/bin $path ) set nnodes = `scontrol show job $SLURM_JOBID|grep NodeList|sed 's/=/\t/'|gawk '{print $2}'|tail -n 1` sed -i "2s/^/%LindaWorkers=$nnodes\n/" g16.g16in sed -i '3s/^/%UseSSH\n/' g16.g16in sed -i "s/nprocshared.*/nprocshared=$ppn./" g16.g16in setenv GAUSS_SCRDIR /home/me/scratch setenv GAUSS_EXEDIR /opt/gaussian/g16a/g16 setenv GAUSS_ARCHDIR /opt/gaussian/g16a/g16/arch setenv GAUSS_BSDDIR /opt/gaussian/g16a/g16/bsd setenv GAUSS_LEXEDIR /opt/gaussian/g16a/g16/linda-exe /opt/gaussian/g16a/g16/g16< $infile > $outfile }
The slurm partition linda has all the nodes that has g16.

14 June 2017

638. ECCE on Centos 7

I use the minimal centos 7 iso from http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1611.iso

It was pretty straightforward otherwise:

su
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 bzip2 perl-Env
exit
mkdir ~/tmp
cd ~/tmp
Download ecce from http://ecce.pnl.gov/using/download.shtml into ~/tmp 
tar xvf ecce-v7.0-src.tar.bz2
cd ecce-v7.0/
export ECCE_HOME=`pwd`
cd build/
./build_ecce
./build_ecce|tee xerxes.log
./build_ecce|tee mesa.log
./build_ecce|tee wxwidgets.log
./build_ecce|tee wxpython.log
./build_ecce|tee httpd.log
./build_ecce|tee ecce.log

If you want a desktop:
sudo yum -y groups install "GNOME Desktop" 
ECCE asks about netstat as well.

12 June 2017

637. ECCE on Ubuntu 16.04.2

I just tried to build ECCE on Ubuntu LTS 16.04.2 according to http://verahill.blogspot.com/2015/06/611-building-ecce-on-debian-jessie.html and it worked without a hitch. The only things that needed changing were

* from openjdk-7-jdk in debian to openjdk-8-jdk in ubuntu
* src/inv/flclient/flfreetype.c: <ftoutln.h> needed changing to <freetype/ftoutln.h>


28 July 2015

618. Modifying ECCE to work with slurm

UPDATE: ecce stops monitoring the job after 10-20 seconds. The job continues fine though. Working on fixing the monitoring issue. This message will be removed once that's fixed. It was due to $q needing to be lowercase (i.e. 'slurm', not 'Slurm') in eccejobmonitor.



Sun Gridengine has been removed from debian jessie (it's in wheezy and sid). This has given me a good excuse to explore setting up SLURM on my debian cluster. So I did: http://verahill.blogspot.com.au/2015/07/617-slurm-on-debian-jessie-and.html

My setup is very simple, with each node having it's own working directory that they export via NFS to the main node. Also, I never run jobs across several nodes. Because of that, each node has it's own queue. Not how beowulf clusters were supposed to work, but it's the best solution for me (e.g. ROCKS does the opposite -- exports the user dir from the main node, but that makes reading and writing slow where it counts i.e. on the work nodes).

I've currently got this slurm.conf:
ControlMachine=beryllium ControlAddr=192.168.1.1 MpiDefault=none ProctrackType=proctrack/pgid ReturnToService=2 SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid SlurmdSpoolDir=/var/lib/slurm/slurmd SlurmUser=slurm StateSaveLocation=/var/lib/slurm/slurmctld SwitchType=switch/none TaskPlugin=task/none FastSchedule=1 SchedulerType=sched/backfill SelectType=select/linear AccountingStorageType=accounting_storage/filetxt AccountingStorageLoc=/var/log/slurm/accounting ClusterName=rupert JobAcctGatherType=jobacct_gather/none SlurmctldLogFile=/var/log/slurm/slurmctld.log SlurmdLogFile=/var/log/slurm/slurmd.log NodeName=beryllium NodeAddr=192.168.1.1 NodeName=neon NodeAddr=192.168.1.120 state=unknown NodeName=tantalum NodeAddr=192.168.1.150 state=unknown NodeName=magnesium NodeAddr=192.168.1.200 state=unknown NodeName=carbon NodeAddr=192.168.1.190 state=unknown NodeName=oxygen NodeAddr=192.168.1.180 state=unknown PartitionName=All Nodes=neon,beryllium,tantalum,oxygen,magnesium,carbon default=yes maxtime=infinite state=up PartitionName=mpi4 Nodes=tantalum maxtime=infinite state=up PartitionName=mpi12 Nodes=carbon maxtime=infinite state=up PartitionName=mpi8 Nodes=neon maxtime=infinite state=up PartitionName=mpix8 Nodes=oxygen maxtime=infinite state=up PartitionName=mpix12 Nodes=magnesium maxtime=infinite state=up PartitionName=mpi1 Nodes=beryllium maxtime=infinite state=up
and sinfo returns
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST All* up infinite 6 idle beryllium,carbon,magnesium,neon,oxygen,tantalum mpi4 up infinite 1 idle tantalum mpi12 up infinite 1 idle carbon mpi8 up infinite 1 idle neon mpix8 up infinite 1 idle oxygen mpix12 up infinite 1 idle magnesium mpi1 up infinite 1 idle beryllium

The first step was to figure out what files to edit:

grep -rs "qsub"
apps/siteconfig/QueueManagers:SGE|submitCommand: qsub ##script##
grep -rs "SGE"
apps/scripts/eccejobmonitor: &MsgSendUp("SGE job id '$id' in state '$state'"); [..] apps/siteconfig/Queues:magnesium|queueMgrName: SGE

Here are the files I edited:

apps/siteconfig/QueueManagers:
12 QueueManagers: LoadLeveler \ 13 Maui \ 14 EASY \ 15 PBS \ 16 LSF \ 17 Moab \ 18 SGE \ 19 Shell\ 20 Slurm
185 Shell|jobIdParseExpression: \ [0-9]+ 186 187 ############################################################################### 188 # SLURM 189 # Simple Linux Utility for Resource Management 190 # 191 # 192 Slurm|submitCommand: sbatch ##script## 193 Slurm|cancelCommand: scancel ##id## 194 Slurm|queryJobCommand: squeue 195 Slurm|queryMachineCommand: sinfo -p ##queue## 196 Slurm|queryQueueCommand: squeue -a 197 Slurm|queryDiskUsageCommand: df -k 198 Slurm|jobIdParseExpression: .* 199 Slurm|jobIdParseLeadingText: job
apps/scripts/eccejobmonitor:
2124 LogMsg "Globus status from eccejobstore: $state"; 2125 } 2126 elsif ($q eq 'slurm') 2127 { 2128 $cmd = "squeue 2>&1"; 2129 if (open(QUERY, "$cmd |")) 2130 { 2131 $gotState = 0; 2132 while () 2133 { 2134 LogMsg "JobCheck: Slurm qstat line: $_"; 2135 if (/^\s*$id/) 2136 { 2137 my $state = (split)[5]; 2138 2139 &MsgSendUp("Slurm job id '$id' in state '$state'"); 2140 2141 if (grep {$state eq $_} qw{R 2142 t}) 2143 { 2144 $status = $JOB_STATE_RUNNING; 2145 } 2146 elsif (grep {$state eq $_} qw{PD}) 2147 { 2148 $status = $JOB_STATE_PENDING; 2149 } 2150 $gotState = 1; 2151 last; 2152 } 2153 } 2154 if ($gotState == 0) 2155 { 2156 if ($gJobCheckState != $JOB_STATE_NONE) 2157 { 2158 $status = $JOB_STATE_DONE; 2159 } 2160 } 2161 close QUERY;

Next set up a new machine (or queue) using ecce -admin. Set up a queue -- you won't be able to select Slurm, so select e.g. PBS. Edit the apps/siteconfig/CONFIG.machinename file to e.g.
1 NWChem: /opt/nwchem/Nwchem/bin/LINUX64/nwchem 2 Gaussian-03: /opt/gaussian/g09d/g09/g09 3 perlPath: /usr/bin/ 4 qmgrPath: /usr/bin/ 5 xappsPath: /usr/bin/ 6 7 Slurm { 8 #!/bin/csh 9 #SBATCH -p mpi8 10 #SBATCH --time=$walltime 11 #SBATCH --output=slurm.out 12 #SBATCH --job-name=$submitFile 13 } 14 15 NWChemEnvironment { 16 PYTHONPATH /opt/nwchem/Nwchem/contrib/python 17 } 18 19 NWChemFilesToRemove{ core *.aoints.* *.gridpts.* } 20 21 NWChemCommand { 22 setenv PATH "/bin:/usr/bin:/sbin:/usr/sbin" 23 setenv LD_LIBRARY_PATH "/usr/lib/openmpi/lib:/opt/openblas/lib:/opt/acml/acml5.3.1/gfortran64_fma4_int64/lib:/opt/acml/acml5.3.1/gfortran64_int64/lib:/opt/intel/mkl/lib/intel64" 24 hostname 25 mpirun -n $totalprocs /opt/nwchem/Nwchem/bin/LINUX64/nwchem $infile > $outfile 26 } 27 28 Gaussian-03FilesToRemove{ core *.rwf } 29 30 Gaussian-03Command{ 31 set path = ( /opt/nbo6/bin $path ) 32 setenv GAUSS_SCRDIR /home/me/scratch 33 setenv GAUSS_EXEDIR /opt/gaussian/g09d/g09/bsd:/opt/gaussian/g09d/g09/local:/opt/gaussian/g09d/g09/extras:/opt/gaussian/g09d/g09 34 /opt/gaussian/g09d/g09/g09< $infile > $outfile 35 echo 0 36 } 37 38 Wrapup{ 39 dmesg|tail 40 find ~/scratch/* -name "*" -user me|xargs -I {} rm {} -rf 41 }
Next, edit apps/siteconfig/Queues -- in my case the machine I created is called neon-slurm:
neon-slurm|queueMgrName: Slurm neon-slurm|queueMgrVersion: 2.0~ neon-slurm|prefFile: neon-slurm.Q
And that's all. You should now be able to submit jobs via slurm. There's obviously a lot more than can be done and configured with SLURM, but this was enough to get me up and running, so that I'm now 'future-proofed' in case SGE never comes back into debian stable.

And here's what it looks like when my ecce-submitted jobs are running:

squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 30 mpi8 In_monom me PD 0:00 1 (Resources) 29 mpi8 b_monome me R 16:12 1 neon 31 mpix12 tl_dimer me R 34:28 1 magnesium

04 June 2015

610. Opening G09 output files in ECCE. A rough method

Update: Note that one thing that's not recognised at the moment are the MOs. Somehow I don't think that should be too difficult. Likewise, I think one should be able to import nwchem files by a little bit of editing like below.

Original post:
When opening a gaussian output file with the ECCE viewer:
* a symlink to the file is put in a subdirectory of /tmp
* the file is parsed for indications as to what the file type is:
+go+cd /tmp/ecce_me/jobs/Gaussian03__HEa24c +go+ln -s /home/me/calcs/test/Outputs/g03.g03out g03.g03out; echo CMDSTAT=$status CMDSTAT=0 +go+grep "Gaussian 98, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 94, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 03, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "%begin%input" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "%begin%input" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Northwest Computational Chemistry Package" /home/me/test/Outputs/g03.g03out; echo CMDSTAT=$status
That's easy enough to fool by simply putting a Gaussian 03 line in the output (assuming that the G09 and G03 output are similar enough).

Here's a successful example, in the sense that ECCE found that it was a Gaussian 03 file:
CMDSTAT=0 +go+grep "Gaussian 98, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 94, Revision" g03.g03out; echo CMDSTAT=$status CMDSTAT=1 +go+grep "Gaussian 03, Revision" g03.g03out; echo CMDSTAT=$status Gaussian 03, Revision CMDSTAT=0 +go+if (-w /tmp/ecce_me/jobs/Gaussian03__7491Sb) echo TRUE TRUE +go+echo $PATH; echo CMDSTAT=$status Word too long. +go+if (-x Gaussian-03.expt) echo TRUE +go+exit; echo GOODBYE exit; echo GOODBYE

However, it fails to detect that Gaussian-03.expt is present and executable (both of which are true).

[SOLUTION]

To sort that out and to enable G09 detection, edit apps/data/client/cap/Gaussian-03.edml:
465 <output mimetype="chemical/x-gaussian03-output" type="parse" verifypattern="Gaussian 09, Revision">g03.g03out</output> 466 <output mimetype="chemical/x-gaussian-03-output" type="parse" verifypattern="Gaussian 09, Revision">g03.out</output> 467 <output mimetype="chemical/x-gaussian03-output" type="parse" verifypattern="Gaussian 03, Revision">g03.g03out</output> 468 <output mimetype="chemical/x-gaussian-03-output" type="parse" verifypattern="Gaussian 03, Revision">g03.out</output> .. 480 <importer>${ECCE_HOME}/scripts/parsers/Gaussian-03.expt </importer>
Your G09 files should now open properly (most of the time).

My ecce_env is fine and my runtime_setup.sh file is called by bash, but somehow it wouldn't find the Gaussian-03.expt file. Maybe it has something to do with the use of csh -f

NOTE that the file isn't imported -- it's just opened. It would've been nice if you could actually import the calculation into ECCE. Still, being able to view it is a nice start. 

05 February 2014

551. Very Briefly: Getting ECCE to work with Gaussian 09 (G09) part 3: Energy gradients (EGRADVEC)

This is a really simple fix to make ECCE return the energy gradient vectors for geometry optimisation jobs in G09:

Edit apps/scripts/parsers/gaussian-03.egradvec and comment out lines 38 (if () {... ) and 70 (}):

diff --git a/ecce-v7.0/scripts/parsers/gaussian-03.egradvec b/ecce-v7.0/scripts/parsers/gaussian-03.egradvec
index a2f5633..4a4b691 100755
--- a/ecce-v7.0/scripts/parsers/gaussian-03.egradvec
+++ b/ecce-v7.0/scripts/parsers/gaussian-03.egradvec
@@ -35,7 +35,7 @@ $| = 1;
 #Don't parse gradients for runtypes with geometry optimization
 #since we can't match gradients with correct geometry.
 
-if (!($runtype =~ /Geo/i)) {
+#if (!($runtype =~ /Geo/i)) {
   $natom = 0;
   while () {
     if (/-----/) { last; }
@@ -67,4 +67,4 @@ if (!($runtype =~ /Geo/i)) {
   }
   print "units:\nHartree/Bohr\n";
   print "END\n";
-}
+#}
-- 


550. Briefly: Getting ECCE to work with Gaussian 09 (G09) part 2: Geometry trace when using NoSymm

I've made a couple of posts about how to modify ECCE to work better in general, but in particular with Gaussian 09  (G09).

See here for some of the previous posts:
Adding new basis sets, part 1: http://verahill.blogspot.com.au/2013/06/455-adding-nwchem-basis-sets-to-ecce.html
Adding new basis sets, part 2:  http://verahill.blogspot.com.au/2013/06/456-adding-nwchem-basis-sets-to-ecce.html
Adding new exchange/correlation functionals:
http://verahill.blogspot.com.au/2013/12/533-adding-new-exchangecorrelation.html
Adding new options to ECCE
http://verahill.blogspot.com.au/2013/12/534-adding-new-options-to-ecce-adding.html
Getting ECCE to read frequency calc output from G09 calcs:
http://verahill.blogspot.com.au/2013/12/536-briefly-getting-ecce-to-work-with.html


Either way, I've noticed that when I'm using the NoSymm option during optimisation ECCE fails to import the geometries from the geometry steps.
No geometry trace option


What is even worse is that if you use an optimisation job like that as the basis for another job by selecting Duplicate Setup with Last Geometry ECCE will in fact use the starting geometry -- not the optimised one.

Luckily the fix is simple -- edit apps/parsers/gaussian-03.desc and add the following lines:
[GEOMTRACE] Script=gaussian-03.geomtrace Begin=Z-Matrix orientation\: Skip=5 Frequency=all End=-------------------------------------- [END]


You can now 'Reconnect job monitoring' also to your old jobs if you still have access to the run directory. Either way, the view will now be a sweet one:
Et voila: A geometry trace

17 December 2013

536. Briefly: Getting ECCE to work with Gaussian 09 (G09) part 1: frequency calcs

I'm slowly looking at improving the support for G09 in ECCE. One of the things that haven't worked in the past is visualising frequency calcs.

Since I'm not using G03 I've been content with editing the g03 files so that they work with G09. My changes will be submitted upstreams at a later point.

Anyway, turns out this was a very simple one.

How ECCE works:
data is extracted from the output through the use of perl parser scripts. These are located in apps/scripts/parsers, and are fairly clearly named.

The script that deals with Gaussian vibrational analyses is called gaussian-03.vib

To use it manually with a gaussian 'log' file (here called g03.output), do
./gaussian-03.vib < g03.output

So far so easy. However, if you use it on a g09 output file you'll end up with a single message: 'Zero atoms'.

Turns out that the reason is that the script looks for instances of 'Atom AN', with a single white space between m and N. In G09, however, there are two white spaces: 'Atom AN'.

The fix:
So, edit line 277:
276     while ()  {
277       if (/Atom AN/) {
278         last;

and change it to
276     while ()  {
277       if (/Atom\s*AN/) {
278         last;

Do the same thing with line 315:
314     while ()  {
315       if (/Atom\s*AN/) {
316         last;

Done!

05 December 2013

534. Adding new options to ECCE -- adding solvation models for G03 (G09)

To minimize the amount of manual editing of my input files I've started to modify the menus in ECCE. One thing that was missing before was the option of selecting a solvation model for Gaussian jobs. I've added that now.

I will eventually submit my changes upstreams, but for now I'll just post a clunky list of changes that I've made:
There are two files to edit:

apps/scripts/codereg/ged03theory.py.

Add the following right after the DFT options section and before the MP options section (ca line number 273 in my case)
#Theory options solvation -CAO sovSizer = EcceBoxSizer(self, label = "Solvation", cols = 2) sovLeftSizer = EcceVBoxSizer() sovRightSizer = EcceVBoxSizer() #Use solvation self.useSCRF = EcceCheckBox(self, #useCosmo label = " Use SCRF" name = "ES.Theory.SCF.UseSCRF", default = False) sovLeftSizer.AddWidget(self.useSCRF, border = EcceGlobals.BorderDefault) #SCRF type scrfChoice = ["PCM", "CPCM", "IPCM", "SCIPCM", "SMD", "Dipole"] self.scrf = EcceComboBox(self, choices = scrfChoice, name = "ES.Theory.SCF.SCRF", label = "SCRF type:", default = 0) sovRightSizer.AddWidget(self.scrf, border = EcceGlobals.BorderDefault) #Solvent type solventChoice = ["Water", "Acetonitrile", "Methanol", "Ethanol", "Manual", "Benzene", "Chloroform", "Diethylether", "Dichloromethane", "Dichloroethane", "Carbontetrachloride", "Toluene", "Chlorobenzene", "Nitromethane", "Heptane", "Aniline", "Acetone", "Tetrahydrofuran", "Dimethylsulfoxide", "Argon", "Krypton", "Xenon", "n-Octanol", "1-Butanol" "Cyclohexane", "Isoquinoline", "Quinoline", ] self.solvent = EcceComboBox(self, choices = solventChoice, name = "ES.Theory.SCF.Solvent", label = "Solvent:", default = 0) sovRightSizer.AddWidget(self.solvent, border = EcceGlobals.BorderDefault) self.scrfDielec = EcceFloatInput(self, default = 78.4, name = "ES.Theory.SCF.Dielectric", label = "Dielectric Constant:", hardRange = "(0..)", unit = "Debye") sovRightSizer.AddWidget(self.scrfDielec, border = EcceGlobals.BorderDefault) sovSizer.AddWidget(sovLeftSizer, flag = wx.ALL) sovSizer.AddWidget(sovRightSizer, flag = wx.ALL) self.panelSizer.Add(sovSizer) #End theory options solvation -CAO

Also add the following to the def CheckDependency(self) block, right before the "if (EcceGlobals.Category == "MP" or" line:
# SCRF solvation -- CAO if EcceGlobals.Category == "DFT" or EcceGlobals.Category == "SCF": self.solvent.Enable(self.useSCRF.GetValue()) self.scrf.Enable(self.useSCRF.GetValue()) self.scrfDielec.Enable(self.useSCRF.GetValue() and self.solvent.GetValue() == "Manual") # end SCRF

Edit apps/scripts/parsers/ai.gauss03 and put the following somewhere in the file.
############################################################################## # # Description: # SCRF options field -CAO # ############################################################################## sub SCRFOptions { my($options,$result); $result = ""; $options = ""; #scrf type if ($AbiDict{"ES.Theory.SCF.UseSCRF"}) { if ($AbiDict{"ES.Theory.SCF.SCRF"} eq "" ) { $options .= "PCM,"; } else {$options .= ($AbiDict{"ES.Theory.SCF.SCRF"}).","}; # solvent/dielectric if ($AbiDict{"ES.Theory.SCF.Solvent"} eq "Manual") { if (defined($AbiDict{"ES.Theory.SCF.Dielectric"})) { $options .= "Dielectric=".$AbiDict{"ES.Theory.SCF.Dielectric"}.""; } } elsif ($AbiDict{"ES.Theory.SCF.Solvent"} eq "") { $options .= "Solvent=water"; } else { $options .= "Solvent=".$AbiDict{"ES.Theory.SCF.Solvent"}; } if ($options ne "") { $result = "SCRF=("; $result .= $options; $result .= ") "; } return $result; } }
Also add the following right below the "$route .= &SCFOptions;" line:
$route .= &SCRFOptions;

And you're done:

03 December 2013

533. Adding a new Exchange/Correlation functional to ECCE. M06 for G03 (G09)

Nothing fancy here. I'd just like to be able to select the M06 functional, which is available in G09, using the ECCE interface.

At some point in the future I might set up separate files for G09, but for now I run G09 using the G03 files in ECCE.

See here and here for how to add basis sets to ECCE.

You'll need to edit 2-3 files. I did this in ECCE v7.0.

Edit apps/scripts/codereg/ged03theory.py
185 xcFuncChoice = ["None", 186 "M06 (hybrid)", 187 "SVWN 5 (local)", 188 "SVWN 1/RPA (local)", 189 "BLYP (nonlocal)",
Edit apps/scripts/parsers/ai.gauss03
635 if ($xcFun eq "SVWN 1/RPA (local)") {# convert our terminology to Gaussian's 636 $result = "SVWN"; 637 } elsif ($xcFun eq "SVWN 5 (local)") { 638 $result = "SVWN5"; 639 } elsif ($xcFun eq "M06 (hybrid)") { 640 $result = "M06"; 641 } elsif ($xcFun eq "BLYP (nonlocal)") {

Editing apps/scripts/parsers/Gaussian-03.expt isn't necessary to get this to work, but I did it anyway. Not sure if it 'does' anything:
557 if ($method =~ /b.*3lyp/ || 558 $method =~ /m06/ || 559 $method =~ /bhandh/ || 560 $method =~ /vscx/ || 561 $method =~ /hcth407/ || 562 $method =~ /hcth147/ ||

You should now be able to select M06 in the Theory Details dialogue:


28 August 2013

503. (relaxed) PES scanning in Nwchem revisited.

Update 2: The coordinates are actually gradients, and so aren't terribly informative to a casual user like myself. See this post for how to extract the geometries properly: http://verahill.blogspot.com.au/2013/08/506-extracting-optimized-structures.html


Update:
Please note that the coordinates in square brackets ([]) in the python output are not raw coordinates for the atoms in the molecule -- I haven't quite figured out how they scale, but it's not a simple matter of just multiplying. The energies are good though, and you can always extract the coordinates the slow and painful way by manually going through the output.

Another issue which should be stressed is that scan_input(geom,[1.398],[3.398],19,'dft',task_optimize) does not do the end points -- i.e. you won't get the energy for a bond length of 1.398, and you won't get the energy for a bond length of 3.398. Instead you'll get 19 data points in between these. It's a bit...awkward.

Original post:
A long time ago I made a post on doing potential energy surface (PES) scans in nwchem using python.

This is a post giving PES another look. The impetus for the post is that I'm tired of Gaussian failing and being opaque about the whole procedure.

The following page was of great help: http://www.fqt.izt.uam.mx/html/software_fqt/user/node34.html

NOTE: you'll need to compile nwchem with python support. See e.g. http://verahill.blogspot.com.au/2013/06/449-nwchem-63-updated-sources-compiling.html (the post is a bit messy, but persevere -- it's not that difficult)

On Debian the key is to change
    EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl
to
    EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl -lssl -lz

in config/makefile.h before compiling. It's not necessary on RHEL clones.

Below I'll show three examples:
* a simple bond dissociation reaction. I also discuss the use of 'constant', and task_energy vs task_optimize.
* an SN2 reaction (CH3Br + I-)
* a 2D/parallel PES scan of ethane ( C-C bond length, H-C-C angle). I also show constant vs free variables.


Example 1.
Breaking the C-O bond in methanol

I set this up in ecce (see e.g. next example), but you don't have to. The input file I used was the following:
scratch_dir /scratch Title "meoh_pes" Start meoh_pes echo charge 0 geometry autosym units angstrom C 0.0351714 0.00548884 0.0351714 H -0.617781 -0.634073 0.667983 H 0.667983 -0.634073 -0.617781 H -0.605139 0.646470 -0.605139 O 0.839603 0.818768 0.839603 H 1.38912 0.201564 1.38912 end ecce_print ecce.out basis "ao basis" cartesian print H library "3-21G" O library "3-21G" C library "3-21G" END dft mult 1 direct XC b3lyp grid fine iterations 99 mulliken end driver default maxiter 888 end python from nwgeom import * geom = ''' geometry adjust zcoord bond 1 5 %f cccc constant end end ''' results=scan_input(geom,[1.398],[3.398],19,'dft',task_optimize) for i in range(0,len(results)): print results[i][0][0],results[i][1] end task python
The PES bit is highlighted in blue. Note the 'constant' keyword -- if you omit that the bond length will initially be set to whatever you define it to in your scan, but it can relax back to the optimum length. If you DO set 'constant' everything BUT that bond will be relaxed. Most likely this is what you will want to do.

Also note that a constrained (i.e. not relaxed) PES scan can be done by doing task_energy instead of task_optimize.

ECCE can't quite handle the textual output (alt+O) since there are lines that are too long. The output is properly written though -- you'll just have to look in the Output folder of the job. The ecce.out file works fine though.

The job takes 90-100 seconds on an old 3-core node (AMD Athlon II X3).


The very end of the output file has all the results, but in a non-obvious way:
1.498 (-115.07289914310056, [-0.00130778291169336, 0.01798903956433226, 0.0, -4.009155466250247e-05, 1.693340302064139e-05, -6.637550254401381e-06, -4.009155466250247e-05, 1.693340302064139e-05, 6.637550254401381e-06, 2. 4514244186701895e-05, -1.5885649893555842e-05, 0.0, 0.0012636893525275195, -0.018041103298149008, 0.0, 9.97624242821682e-05, 3.4082577691996185e-05, 0.0]) (-114.8737952986994, [-4.7287277448850376e-05, 0.030029200359777717, 0.0, -1.3711175166353229e-06, -8.452926738775068e-08, 9.941241931599176e-07, -1.3711175166353229e-06, -8.452926738775068e-08, -9.941241931599176e-07, 8. 167348279908282e-07, -2.5820569179275075e-06, 0.0, 4.871429991895604e-05, -0.030027845123621805, 0.0, 4.984777179639632e-07, 1.3958792967685985e-06, 0.0]) 1.498 (-115.07289914310056, [-0.00130778291169336, 0.01798903956433226, 0.0, -4.009155466250247e-05, 1.693340302064139e-05, -6.637550254401381e-06, -4.009155466250247e-05, 1.693340302064139e-05, 6.637550254401381e-06, 2. 4514244186701895e-05, -1.5885649893555842e-05, 0.0, 0.0012636893525275195, -0.018041103298149008, 0.0, [..] 3.198 (-114.87977711993531, [-0.00018979360652668711, 0.033296276783081655, 0.0, -2.3787379704320877e-06, 1.7510009376556918e-06, 1.3530564600128248e-06, -2.3787379704320877e-06, 1.7510009376556918e-06, -1.3530564600128248e-06, 8. 24207064487048e-06, -8.055936327900498e-07, 0.0, 0.00018027576986845428, -0.03329589479259992, 0.0, 6.033241931824307e-06, -3.0783987173960137e-06, 0.0]) 3.298 (-114.8737952986994, [-4.7287277448850376e-05, 0.030029200359777717, 0.0, -1.3711175166353229e-06, -8.452926738775068e-08, 9.941241931599176e-07, -1.3711175166353229e-06, -8.452926738775068e-08, -9.941241931599176e-07, 8. 167348279908282e-07, -2.5820569179275075e-06, 0.0, 4.871429991895604e-05, -0.030027845123621805, 0.0, 4.984777179639632e-07, 1.3958792967685985e-06, 0.0])
All in all, there are 58 lines for 19 steps. I think that there are three things happening -- firstly, the line in blue is the output from the 19th step, and that somehow gets mixed in with the output from all the calculations. Secondly, the structure and energy of each step is reported twice at a time. Thirdly, the optimised structures/energies are reported one more time by injecting them into the output, like this:
A
S
A
B
B
C
C
D
D
A
E
E
B

where A is the first step, S is the 19th step etc. This way you get 19x3+1=58 lines. This is clearly idiotic.

Instead, you can look through the output and search for 'Scanning NWChem input - results from step' to see all the output for the optimised structures one by one:
Scanning NWChem input - results from step 2 (-115.06618436935011, [-0.0038228970733096973, 0.050051062094932305, 0.0, 2.9196769046224702e-05, -6.928661348853948e-06, 4.746536668570611e-06, 2.9196769046224702e-05, -6.928661348853948e-06, -4.746536668570611e-06, -1.0103262985700079e-05, 1.6491089715894858e-05, 0.0, 0.003767244388907326, -0.05005618579508188, 0.0, 7.362409274846993e-06, 2.489933151654522e-06, 0.0])
In this particular case I can grep my way through by doing
cat nwch.nwout |grep '^(-'|cat -n
1 (-115.07289914310056, [-0.00130778291169336, 0.01798903956433226, 0.0, -4.009155466250247e-05, 1.693340302064139e-05, -6.637550254401381e-06, -4.009155466250247e-05, 1.693340302064139e-05, 6.637550254401381e-06, 2.4514244186701895e-05, -1.5885649893555842e-05, 0.0, 0.0012636893525275195, -0.018041103298149008, 0.0, 9.97624242821682e-05, 3.4082577691996185e-05, 0.0]) 2 (-115.06618436935011, [-0.0038228970733096973, 0.050051062094932305, 0.0, 2.9196769046224702e-05, -6.928661348853948e-06, 4.746536668570611e-06, 2.9196769046224702e-05, -6.928661348853948e-06, -4.746536668570611e-06, -1.0103262985700079e-05, 1.6491089715894858e-05, 0.0, 0.003767244388907326, -0.05005618579508188, 0.0, 7.362409274846993e-06, 2.489933151654522e-06, 0.0]) 3 (-115.05478103866017, [-0.005033784212299788, 0.06848598587431667, 0.0, -1.3396548676491982e-06, -2.5875637174599397e-08, -5.261746410523127e-07, -1.3396548676491982e-06, -2.5875637174599397e-08, 5.261746410523127e-07, 1.4459720645843e-07, -2.8328952926398587e-06, 0.0, 0.005034455335082233, -0.0684825786855032, 0.0, 1.8635897582608418e-06, -5.225422206114883e-07, 0.0]) 4 (-115.04079235517, [-0.005485543277166251, 0.07798880362126945, 0.0, 4.745460307237215e-06, -5.597510268573469e-06, 5.645418744981701e-07, 4.745460307237215e-06, -5.597510268573469e-06, -5.645418744981701e-07, -6.651712157745848e-07, 6.750842351778419e-06, 0.0, 0.00548062073181968, -0.07798086728839469, 0.0, -3.903204054994669e-06, -3.4921546817404114e-06, 0.0]) 5 (-115.02560006674966, [-0.0054233976595857575, 0.08166232318137269, 0.0, -1.659239761503395e-06, -4.376603580866223e-07, 4.4580035316599265e-06, -1.659239761503395e-06, -4.376603580866223e-07, -4.4580035316599265e-06, 3.034808945895362e-06, -6.726118036586015e-06, 0.0, 0.005436665955901393, -0.08164730868562775, 0.0, -1.2984625724410392e-05, -7.4130570159938736e-06, 0.0]) [..] 16 (-114.89364787840326, [-0.0005591249462735259, 0.04018795560035916, 0.0, -5.34666220519675e-07, 1.1370871814235517e-06, 4.809133242467123e-07, -5.34666220519675e-07, 1.1370871814235517e-06, -4.809133242467123e-07, -6.9140095421138525e-06, -3.095664552260277e-06, 0.0, 0.0005695756951453745, -0.040185884820554796, 0.0, -2.467406898132296e-06, -1.2492896190128416e-06, 0.0]) 17 (-114.8863872514371, [-0.00036666056940981573, 0.03667976502852128, 0.0, 2.9101399354747315e-06, -2.094045026924257e-06, -4.933288234976185e-06, 2.9101399354747315e-06, -2.094045026924257e-06, 4.933288234976185e-06, 1.6531622304416516e-07, 1.511517903679191e-07, 0.0, 0.00036162347288279384, -0.03668602744257765, 0.0, -9.484995716624312e-07, 1.0299352320775057e-05, 0.0]) 18 (-114.87977711993531, [-0.00018979360652668711, 0.033296276783081655, 0.0, -2.3787379704320877e-06, 1.7510009376556918e-06, 1.3530564600128248e-06, -2.3787379704320877e-06, 1.7510009376556918e-06, -1.3530564600128248e-06, 8.24207064487048e-06, -8.055936327900498e-07, 0.0, 0.00018027576986845428, -0.03329589479259992, 0.0, 6.033241931824307e-06, -3.0783987173960137e-06, 0.0]) 19 (-114.8737952986994, [-4.7287277448850376e-05, 0.030029200359777717, 0.0, -1.3711175166353229e-06, -8.452926738775068e-08, 9.941241931599176e-07, -1.3711175166353229e-06, -8.452926738775068e-08, -9.941241931599176e-07, 8.167348279908282e-07, -2.5820569179275075e-06, 0.0, 4.871429991895604e-05, -0.030027845123621805, 0.0, 4.984777179639632e-07, 1.3958792967685985e-06, 0.0])
Not pretty, but manageable.
cat nwch.nwout |grep '^(-'|sed 's/\,/\t/g;s/(\([^)]*\))/\1/g'|cat -n|gawk '{print $1,$2}' > profile.dat

and then plot it:


Example 2.
SN2 reaction between iodide and bromomethane

You can set up your calc however you want, but ECCE is easier than anything else.

Draw bromomethane, then throw in an iodine atom. Adjust the angle across Br-C-I to 180 degrees, and set the C to I distance to 3 Ã….


Set up the calculation -- in this case I used b3lyp/def2-svp
Edit the input and add
python from nwgeom import * geom = ''' geometry adjust zcoord bond 1 6 %f cccc constant end end ''' results=scan_input(geom,[3.00],[1.5],20,'dft',task_optimize) for i in range(0,len(results)): print results[i][0][0],results[i][1] end task python

(Delete 'task dft optimize')

You'll now have the following input file:
scratch_dir /scratch
Title "sn2_br"

Start  sn2_br

echo

charge -1

geometry noautosym units angstrom
 C     0.00000     0.00000     0.00000
 H     -0.675500     -0.675500     0.675500
 H     0.675500     -0.675500     -0.675500
 H     -0.675500     0.675500     -0.675500
 Br     1.10274     1.10274     1.10274
 I     -1.73205     -1.73205     -1.73205
end

ecce_print ecce.out

basis "ao basis" spherical print
  H library "def2-svpd"
  Br library "def2-svpd"
  C library "def2-svpd"
  I library "def2-svpd"
END
ECP
  I library "def2-ecp"
END

dft
  mult 1
  direct
  XC b3lyp
  grid fine
  iterations 99
  mulliken
end

driver
  default
  maxiter 99
end


python
from nwgeom import *
geom = '''
    geometry adjust
        zcoord
            bond 1 6 %f cccc constant
        end
    end
'''
results=scan_input(geom,[3.00],[1.5],20,'dft',task_optimize)
for i in range(0,len(results)):
    print results[i][0][0],results[i][1]
end


task python
Launch it and wait...eventually (2h 30 min on a slow three-core node) you'll get an output like the one below. Note that I didn't pre-optimise the bromomethane, so there's a bit of a drop in energy at the beginning. Likewise, I let the C-I distance get so short that the energy is rising rapidly at the end
Structure at the beginning

Transition-state-ish structure

Product


Example 3:
Two-dimensional PES scan

I'll keep this brief. First we do a scan where we use 'constant' for the angle, but not the bond length:
scratch_dir //scratch Title "2d_pes-1" Start 2d_pes-1 echo charge 0 geometry noautosym units angstrom C -2.51242e-66 1.67495e-66 -0.767732 H -0.722530 0.722530 -1.16548 H -0.264464 -0.986995 -1.16548 H 0.986995 0.264464 -1.16548 C 2.51242e-66 -2.51242e-66 0.767732 H 0.264464 0.986995 1.16548 H -0.986995 -0.264464 1.16548 H 0.722530 -0.722530 1.16548 end ecce_print ecce.out basis "ao basis" cartesian print H library "6-31G" C library "6-31G" END dft mult 1 direct XC b3lyp grid fine iterations 99 mulliken end driver default end python from pes_scan import pes_scan geom = ''' geometry noprint adjust zcoord bond 1 5 %f cc angle 2 1 5 %f hcc constant end end ''' results = pes_scan(geom, \ [1.535, 111.269], [1.800, 90], 5, 'dft', task_optimize) end task python

And the output:
What's happening is that the bond length ends up being the same no matter what we initially set it to

If we instead set constant for the bond as well:
python from pes_scan import pes_scan geom = ''' geometry noprint adjust zcoord bond 1 5 %f cc constant angle 2 1 5 %f hcc constant end end ''' results = pes_scan(geom, \ [1.535, 111.269], [1.800, 90], 5, 'dft', task_optimize) end task python

And we get:

17 June 2013

456. Adding NWChem basis sets to ECCE. Part 2. A solution: nwchem2ecce.py

UPDATED!

I've moved the finished scripts to here:
https://sourceforge.net/projects/nwbas2ecce/

They work! I've also added a number of converted basis sets to the sourceforge repo under 'examples'. You'll also find example ecp and ECPOrbital files.

Phew...

Here's the README:
The programmes are not 'intelligent' -- they won't check that you are doing something reasonable. Bad input = bad output. __Installation__: Download eccepag and nwbas2ecce They are both python (2.7) programmes, so you will need to install python to run them. On linux, this is normally very easy. E.g. on debian, run 'sudo apt-get install python2.7' and you are done. If you want, you can put the files in /usr/local/bin and do 'sudo chmod +x /usr/local/bin/eccepage' 'sudo chmod +x /usr/local/bin/nwbas2ecce' and you will be able to call the scripts from any directory. __Usage__ nwbas2ecce can turn a full basis set, or a, ECP basis set, into an ECCE compatible set of basis set files. Typically, an nwchem basis set consists of a single file, e.g. 3-21g. It can also be divided into several files, e.g. def2-svp and def-ecp, where the effective core potentials (ecps) are in def2-ecp. Other basis set files, like lanl2dz_ecp, contains both the orbital and the contraction parts. Typically, a ECCE basis set suite consists of: basis.BAS basis.BAS.meta basis.POT (for ECP) basis.POT.meta (for ECP) Sometimes polarization and diffuse functions are separated from the main .BAS file. E.g. 3-21++G* consists of 3-21G.BAS 3-21GS.BAS POPLDIFF.BAS , in addition to the meta files. The meta files are just markup-language type files with e.g. references. Note that you don't HAVE to break up the basis set components like this. Since the basis set data can be broken up into smaller files, the overall basis set is defined as an entry in a category file. For example, 3-21G is defined in the category file 'pople', and points to 3-21G.BAS. 3-21G* is also defined in pople, but point to both 3-21G.BAS and 3-21GS.BAS. ECP works in a similar way, by combining a .BAS and a .POT file. Note that the .POT files look different from the .BAS files. nwbas2ecce generates .BAS and .POT files based on whether there are basis/end or ecp/end sections in the nwchem basis set file. If there are both, both POT and BAS files are generated. All these files are contained in server/data/Ecce/system/GaussianBasisSetLibrary Finally, you need to generate .pag and .dir files that go into the server/data/Ecce/system/GaussianBasisSetLibrary/.DAV directory. The .dir file is always empty, while the .pag file is unfortunately a binary file. eccepag can, however, generate it with the right input. See e.g. http://verahill.blogspot.com.au/2013/06/455-adding-nwchem-basis-sets-to-ecce.html for more detailed information __Example__ We'll use def2-svp as an example. The nwchem basis set file def2-svp contains the basis set, while def2-ecp contains the core potentials. Use def2-svp to generate DEF2_SVP.BAS, DEF2_SVP.BAS.meta. Use def2-ecp to generate DEF2_ECP.POT, DEF2_ECP.POT.meta. As part of the generation, .descriptor files are also generated. These contain information that should go into the category file(s). Then generate the .pag files for both the POT and the BAS files, and touch the .dir files into existence. Do like this: nwbas2ecce -i def2-svp -o DEF2_SVP.BAS -n 'def2-svp' nwbas2ecce -i def2-ecp -p DEF2_ECP.POT -n 'def2-ecp' eccepag -n def2-svp -t ECPOrbital -c ORBITAL -y Segmented -s Y -o DEF2_SVP.BAS.pag eccepag -n def2-ecp -t ecp -c AUXILIARY -o DEF2_ECP.POT.pag NOTE: I don't actually know if def2-svp is segmented, and spherical. I don't think it matters for the .pag file generation. Also note that most inputs are case sensitive. Look at a similar .pag file for hints. You now have the following files: DEF2_ECP.POT DEF2_ECP.POT.descriptor DEF2_ECP.POT.meta DEF2_ECP.POT.pag DEF2_SVP.BAS DEF2_SVP.BAS.descriptor DEF2_SVP.BAS.meta DEF2_SVP.BAS.pag Copy the files. Note that you need to select the correct target directory, and that will vary with where you installed ECCE. I'll assume it's in /opt/ecce cp DEF2* /opt/ecce/server/data/Ecce/system/GaussianBasisSetLibrary cd /opt/ecce/server/data/Ecce/system/GaussianBasisSetLibrary mv *.pag .DAV/ touch .DAV/DEF2_SVP.BAS.dir .DAV/DEF2_ECP.POT.dir cat DEF2_SVP.BAS.descriptor >> ECPOrbital cat DEF2_ECP.POT.descriptor >> ECPOrbital cat DEF2_ECP.POT.descriptor >> ecp Edit ECPOrbital so that it reads: name= def2-svp files= DEF2_SVP.BAS DEF2_ECP.POT atoms= 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 atoms= 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
/pre>

455. Adding NWChem basis sets to ECCE. Part 1. The formats

I've written a python script that cam
1. do automatic conversion of nwchem basis set files to .BAS and .POT
2. generate entries that can be added to the category file

What it currently can't do is generate a .pag file.

The python script is not in this post. I'll release it soon though.


The structure:
ECCE stores basis sets in server/data/Ecce/system/GaussianBasisSetLibrary/.

The number of files associated with a basis set varies, and the way a basis set is set up seems to vary as well depending on who added it.

Each basis set needs at least the following files:
basis.BAS
basis.BAS.meta
.DAV/basis.BAS.pag
.DAV/basis.BAS.dir

In addition, the basis set needs to be added to the correct category by being added to one of the following files:

Charge correlation_consistent DFTOrbital diffuse ecp ECPOrbital Exchange other_generally_contracted other_segmented polarization pople rydberg
e.g. 6-31G goes to pople, while LANL2DZ/ECP goes to ECPOrbital.

Looking at the basis set tool in ECCE you have the following categories/subcategories:
Orbital: Pople Shared, Other Segmented, Corr. Consistent, Other Gen. Contr., ECP Orbital, DFT Orbital. Auxiliary: Polarization, Diffuse, Rydberg. ECP: DFT: Charge Fitting, Exchange Fitting.
What it means is that you can 'mix and match' by adding your .BAS or .POT files to different category files (e.g. you can have LANL2DZ dp both ECPOrbital, ecp and polarization, all at the same time. See below for how basis sets can be broken up.

Example: The simple cases: 3-21G, 3-21G*, 3-21++G*
For a basis set like 3-21G there are two files: 3-21G.BAS and 3-21G.BAS.meta.
In addition grep shows that there's an entry in the file pople for 3-21G.

The .BAS file:
The entry for C in 3-21G.BAS looks like this:
atom=C contraction shell=S num_primitives=3 num_coefficients=1 172.2560 0.0617669 25.91090 0.358794 5.533350 0.700713 contraction shell=SP num_primitives=2 num_coefficients=2 3.664980 -0.395897 0.236460 0.770545 1.215840 0.860619 contraction shell=SP num_primitives=1 num_coefficients=2 0.195857 1.000000 1.000000
Nothing too strange. For example, the nwchem format for C in 3-21g is:
basis "C_3-21G" CARTESIAN C S 172.2560000 0.0617669 25.9109000 0.3587940 5.5333500 0.7007130 C SP 3.6649800 -0.3958970 0.2364600 0.7705450 1.2158400 0.8606190 C SP 0.1958570 1.0000000 1.0000000 end
Writing a python script that translates between the two is simple.


The .BAS.meta file:
The 3-21G.BAS.meta file looks like this:
references Elements References -------- ---------- H - Ne: J.S. Binkley, J.A. Pople, W.J. Hehre, J. Am. Chem. Soc 102 939 (1980) Na - Ar: M.S. Gordon, J.S. Binkley, J.A. Pople, W.J. Pietro and W.J. Hehre, J. Am. Chem. Soc. 104, 2797 (1983). K - Ca: K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 7, 359 (1986). Ga - Kr: K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 7, 359 (1986). Sc - Zn: K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 8, 861 (1987). Y - Cd: K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 8, 880 (1987). Cs : A 3-21G quality set derived from the Huzinage MIDI basis sets. E.D. Glendening and D. Feller, J. Phys. Chem. 99, 3060 (1995) references info 3-21G Split Valence Basis ------------------------- Elements Contraction References H - He: (3s) -> [2s] J.S. Binkley, J.A. Pople and W.J. Hehre, Li - Ne: (6s,3p) -> [3s,2p] J. Am. Chem. Soc. 102, 939 (1980). Na - Ar: (9s,6p) -> [4s,3p] M.S. Gordon, J.S. Binkley, J.A. Pople, W.J. Pietro and W.J. Hehre, J. Am. Chem. Soc. 104, 2797 (1983) K - Ca: (12s,9p) -> [5s,4p] K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 7, Ga - Kr: (12s,9p,3d) -> [5s,4p,1d] 359 (1986). Sc - Zn: (12s,9p,3d) -> [5s,4p,2d] K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 8, 861 (1987). Rb - Sr: (15s,12p,3d)-> [6s,5p,1d] Y - Cd: (15s,12p,6d)-> [6s,5p,3d] K.D. Dobbs, W.J. Hehre, J. Comput. Chem. 8, In - I: (15s,12p,6d)-> [6s,5p,2d] 880 (1987). Cs : (18s,12p,6d)-> [6s,5p,2d] A 3-21G quality set derived from the Huzinage MIDI basis sets. E.D. Glendening and D. Feller, J. Phys. Chem. 99, 3060 (1995). The 3-21G basis set contains the same number of Gaussian primitives as the STO-3G basis, but the valence electrons are described with two functions per AO instead of one. In most cases the 3-21G basis set gives results which are as good as the more expensive 4-31G and 6-31G sets. 3-21G Atomic Energies ROHF State UHF (noneq) ROHF (noneq) ROHF(equiv) HF Limit (equiv) ----- ---------- ----------- ----------- --------- H 2-S -0.496199 -0.496199 -0.496199 -0.50000 He 1-S -2.835680 -2.835680 -2.835680 -2.86168 Li 2-S -7.381513 -7.381513 -7.381513 -7.43273 Be 1-S -14.486820 -14.486820 -14.486820 -14.57302 B 2-P -24.389762 -24.389634 -24.148989 -24.52906 C 3-P -37.481070 -37.480389 -37.480389 -37.68862 N 4-S -54.105390 -54.103658 -54.103658 -54.40094 O 3-P -74.393657 -74.392512 -74.391782 -74.80940 F 2-P -98.845009 -98.844645 -98.844230 -99.40935 Ne 1-S -127.132546 -127.803824 -127.803824 -128.54710 Na 2-S -160.854064 -160.854041 -160.854041 -161.85891 Mg 1-S -198.468103 -198.468103 -198.468103 -199.61463 Al 2-P -240.551046 -240.551024 -240.551010 -241.87671 Si 3-P -287.344431 -287.344419 -287.344393 -288.85436 P 4-S -339.000079 -339.000027 -339.000027 -340.71878 S 3-P -395.551336 -395.551083 -395.550591 -397.50490 Cl 2-P -457.276552 -457.276414 -457.276096 -459.48207 Ar 1-S -524.342962 -524.342962 -524.342962 -526.81751 K 2-S -596.152980 -596.152923 -596.152923 -599.16479 info comments 2/16/95 - DFF - Modify the format of the literature citation. 12/07/93 - SJB - Add Nb to Xe. 8/4/93 - DFF - Add Y and Zr. 12/2/92 - DFF - Add Rb and Sr. 7/13/90 - DFF - Original creation of this file from MIA basis set library. comments
Again, most of this can be extracted using a shell/python/perl script from the corresponding 3-21g nwchem basis set file.

The entry for 3-21G in 'pople':
name= 3-21G files= 3-21G.BAS atoms= 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
This simple seems to be a list over the files that describe the basis set and the elements supported. Can be autogenerated using a script.

Intermission: polarization and diffuse orbitals, and ECP.
At this stage it's pretty simple. We now have a rough idea of what's needed. We just need to understand how to expand our basis sets.

For 3-21G* and 3-21++G* the polarisation and diffuse orbitals are separated into 3-21GS-AGG.BAS and 3-21GS.BAS, and 3-21PPGS-AGG.BAS and 3-21GS.BAS, and POPLDIFF.BAS. All -AGG.BAS files are empty, so I'm not sure why they are there.

Anyway, this might make it a bit clearer:
3-21G = 3-21G.BAS 3-21G* = 3-21G.BAS + 3-21GS.BAS 3-21++G* = 3-21G.BAS + 3-21GS.BAS + POPLDIFF
What happens to e.g. pople is this:
name= 3-21G* files= 3-21GS-AGG.BAS 3-21G.BAS 3-21GS.BAS atoms= H He Li Be B C N O F Ne Na Mg Al Si P S Cl Ar atoms= Na Mg Al Si P S Cl Ar name= 3-21++G* files= 3-21PPGS-AGG.BAS 3-21G.BAS POPLDIFF.BAS 3-21GS.BAS atoms= H He Li Be B C N O F Ne Na Mg Al Si P S Cl Ar atoms= H Li Be B C N O F Ne Na Mg Al Si P S Cl Ar atoms= Na Mg Al Si P S Cl
The -AGG.BAS files are empty. The first atoms line corresponds to entries in 3-21G.BAS, while for 3-21G* the second one corresponds to entries in 3-21GS.BAS. Likewise,
atoms= H Li Be B C N O F Ne Na Mg Al Si P S Cl Ar
are entries in POPLDIFF.BAS.

The good news: it's almost identical when it comes to ECP. Here's the ECPOrbital entry for LANL2DZ:
name= LANL2DZ ECP files= LANL2DZ.BAS LANL2DZ.POT atoms= H 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 Pb Bi U Np Pu atoms= 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 Pb Bi U Np Pu
and the ecp entry:
name= LANL2DZ ECP files= LANL2DZ.POT atoms= 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 Pb Bi U Np Pu

The POT file is a little bit different from the .BAS file:
atom=Na ncore=10 lmax=2 ecp_potential%l=2%shell=d potential%num_exponents=5 1 175.5502590 -10.0000000 2 35.0516791 -47.4902024 2 7.9060270 -17.2283007 2 2.3365719 -6.0637782 2 0.7799867 -0.7299393 ecp_potential%l=0%shell=s-d potential%num_exponents=5 0 243.3605846 3.0000000 1 41.5764759 36.2847626 2 13.2649167 72.9304880 2 3.6797165 23.8401151 2 0.9764209 6.0123861 ecp_potential%l=1%shell=p-d potential%num_exponents=6 0 1257.2650682 5.0000000 1 189.6248810 117.4495683 2 54.5247759 423.3986704 2 13.7449955 109.3247297 2 3.6813579 31.3701656 2 0.9461106 7.1241813

.DAV files
The good news: the .DAV/basis.dir file is empty.
The bad news: .DAV/basis.pag is a binary file.
I haven't yet figured out the exact structure of it nor the best way to auto-generate it.
I think the best illustration is to show the od -c output for a few .POT.pag files:
LANL2DZ.POT.pag:
0000000 \b \0 371 003 354 003 345 003 340 003 325 003 312 003 302 003 0000020 233 003 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001620 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 002 D 0001640 A V : \0 h t t p : / / w w w . e 0001660 m s l . p n l . g o v / e c c e 0001700 : \0 M E T A D A T A \0 A U X I L 0001720 I A R Y \0 1 : c a t e g o r y \0 0001740 \0 e c p \0 1 : t y p e \0 \0 L A N 0001760 L 2 D Z E C P \0 1 : n a m e \0 0002000
SBKJC.POT.pag:
0000000 \b \0 371 003 356 003 347 003 342 003 327 003 314 003 304 003 0000020 235 003 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001620 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 0001640 002 D A V : \0 h t t p : / / w w w 0001660 . e m s l . p n l . g o v / e c 0001700 c e : \0 M E T A D A T A \0 A U X 0001720 I L I A R Y \0 1 : c a t e g o r 0001740 y \0 \0 e c p \0 1 : t y p e \0 \0 S 0001760 B K J C E C P \0 1 : n a m e \0 0002000

Trial and error in making files for def2-svp has shown me that you can copy e.g. LANL2DZ.POT.pag to DEF2_ECP.POT.pag, and edit with vim (use binary mode -b) but that you'll need to add enough spaces to the name so that the files both end at the same place. E.g. this works:
0000000 \b \0 371 003 354 003 345 003 340 003 325 003 312 003 302 003 0000020 233 003 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001620 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 002 D 0001640 A V : \0 h t t p : / / w w w . e 0001660 m s l . p n l . g o v / e c c e 0001700 : \0 M E T A D A T A \0 A U X I L 0001720 I A R Y \0 1 : c a t e g o r y \0 0001740 \0 e c p \0 1 : t y p e \0 \0 d e f 0001760 2 - e c p \0 1 : n a m e \0 0002000
but this doesn't (removed a single space at the end of def2-ecp):
0000000 \b \0 371 003 354 003 345 003 340 003 325 003 312 003 302 003 0000020 233 003 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001620 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 002 D 0001640 A V : \0 h t t p : / / w w w . e 0001660 m s l . p n l . g o v / e c c e 0001700 : \0 M E T A D A T A \0 A U X I L 0001720 I A R Y \0 1 : c a t e g o r y \0 0001740 \0 e c p \0 1 : t y p e \0 \0 d e f 0001760 2 - e c p \0 1 : n a m e \0 0001777
Note that the names should correspond to the names of the nwchem basis sets and/or files e.g. either 3-21gs or 3-21G*. Or LANL2DZ ECP or lanl2dz_ecp.

As far as I understand the solution will lie in how WebDAV uses .pag files. I don't know anything about that just yet though.

Anyway, that's it for now. There's now enough information to write your own scripts.

454. If I had a magic wand: stuff I'd fix in ECCE

Development of ECCE isn't as rapid as it used to, and one reason may be that the cost of implementing new features may be increasingly expensive, together with resources being finite.

However, ECCE is open source since about a year. Sure, you may not be able to submit your changes without vetting to a sourceforge git repo, but the good folks at EMSL/PNNL are very open to receiving patches and possibly merging them with the main trunk if you do write them.

Go to the ECCE forum and post improvements if you have made them. The forum is here: http://www.nwchem-sw.org/index.php/Special:AWCforum/sf/id11/General_ECCE_Topics.html

NOTE: as always with open source projects, simply making demands for features and general improvements in the forum, unless very small or highly critical, is probably a bit impolite.

I've made a few abortive attempts at making improvements to ECCE, and as these efforts often go, my success has been rather mixed (I think the migration from getopts to Getop:std is my only real contribution so far). My main talent seems to be in writing posts about ECCE, which I suppose isn't entirely without merit.

However, I'd like to become more involved, even though a significant barrier is the fact that ECCE is written in at least four different languages (java, C, perl, python).

So here's my wish list, which I might be amending with time (hopefully with solutions...)

1. Bugs
* When creating a new directory, all open directories lower in rank auto-close.
Example. Say we have the directory /jobs/catalyst open/expanded. If we create the directory /jobs/transition, /jobs/catalyst and everything below will close. It can be quite annoying since you may lose track of what jobs you were running and where.

* Separate DFT maxiter from SCF maxiter
NOTE: what I wrote below is wrong. DFT;iterations N;end works as advertised in DFT, scf; maxiter N;end is ignored.
Old text: When setting up DFT jobs using the theory editor, section called SCF Convergence really only sets the DFT options. In other words, if you set SCF max iterations to 999, you're really setting the number of DFT iterations, not SCF. It would be nice to add an SCF section to DFT jobs, and rename the SCF section to DFT.

* Can't run command because too many files open
While in reality you actually don't have anything open.
Not sure exactly what causes it, but it's manifested by the ECCE animation (in the left-most button) in the ECCE menu thingy (the small window with buttons for Exit, Organizer, Builder, Viewer, Machine Browser etc.) not stopping, and no window launching. In the terminal the following is shown:
[..] exit; echo GOODBYE Unable to create a socket Error: java.net.SocketException: Too many open files

Doing
lsof |grep ecce
in one case yielded 9784 hits, most of which were of the type
java 18010 31175 me 99u REG 8,6 0 17194388 /home/me/.ecce/ecce-v6.4b/server/activemq/data/kr-store/data/hash-index-blob_ecce_url_property_data-Subscriptions java 18010 31175 me 106u REG 8,6 0 17196148 /home/me/.ecce/ecce-v6.4b/server/activemq/data/kr-store/data/hash-index-topic-data_ecce_ejs_kill java 18010 31175 me 107u REG 8,6 0 17196150 /home/me/.ecce/ecce-v6.4b/server/activemq/data/kr-store/data/hash-index-blob_ecce_ejs_kill-Subscriptions java 18010 31176 me cwd DIR 8,6 4096 16517897 /home/me/.ecce/ecce-v6.4b/apps/bin java 18010 31176 me mem REG 8,6 14014 16919807 /home/me/.ecce/ecce-v6.4b/server/activemq/bin/run.jar java 18010 31176 me mem REG 8,6 367444 16919829 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/log4j-1.2.14.jar java 18010 31176 me mem REG 8,6 467331 16919826 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-beans-2.5.1.jar java 18010 31176 me mem REG 8,6 81403 16919823 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-console-5.1.0.jar java 18010 31176 me mem REG 8,6 455159 16919827 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-context-2.5.1.jar java 18010 31176 me mem REG 8,6 128051 16919828 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/xbean-spring-3.3.jar java 18010 31176 me mem REG 8,6 52915 16919819 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/commons-logging-1.1.jar java 18010 31176 me mem REG 8,6 2141382 16919830 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/derby-10.1.3.1.jar java 18010 31176 me mem REG 8,6 275073 16919825 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-core-2.5.1.jar java 18010 31176 me mem REG 8,6 16030 16919820 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-j2ee-management_1.0_spec-1.0.jar java 18010 31176 me mem REG 8,6 32359 16919821 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-jms_1.1_spec-1.1.1.jar java 18010 31176 me mem REG 8,6 2315247 16919822 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-core-5.1.0.jar java 18010 31176 me 12r REG 8,6 14014 16919807 /home/me/.ecce/ecce-v6.4b/server/activemq/bin/run.jar java 18010 31176 me 21r REG 8,6 2141382 16919830 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/derby-10.1.3.1.jar java 18010 31176 me 22r REG 8,6 367444 16919829 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/log4j-1.2.14.jar java 18010 31176 me 23r REG 8,6 467331 16919826 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-beans-2.5.1.jar java 18010 31176 me 24r REG 8,6 455159 16919827 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-context-2.5.1.jar java 18010 31176 me 25r REG 8,6 275073 16919825 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-core-2.5.1.jar java 18010 31176 me 26r REG 8,6 128051 16919828 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/xbean-spring-3.3.jar java 18010 31176 me 27r REG 8,6 81403 16919823 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-console-5.1.0.jar java 18010 31176 me 28r REG 8,6 2315247 16919822 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-core-5.1.0.jar java 18010 31176 me 29r REG 8,6 52915 16919819 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/commons-logging-1.1.jar java 18010 31176 me 30r REG 8,6 16030 16919820 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-j2ee-management_1.0_spec-1.0.jar java 18010 31176 me 31r REG 8,6 32359 16919821 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-jms_1.1_spec-1.1.1.jar

And it repeats. I don't know why -- I guess files are opened and never closed.

* MD bugs?
Hammering out MD related bugs. I don't understand the ECCE support for MD well enough to know what is a bug and what is a feature issue, but I do know that I've had issues getting MD sims running through simple point and click. So I'm not even sure that there are MD related bugs -- but you do get the impression that there are.

Luckily there are people putting up tutorials online: http://saccharides.blogspot.tw/2013/06/ecce-md-calculation.html

* Long lines in nwchem input
There's a bug when dealing with lines longer than 254 chars. Today (18th of June 2013) I encountered it for the first time in a situation unrelated to pasting BSE code -- this time the ecce_print line was simply too long. Read more here about the bug: http://verahill.blogspot.com.au/2013/02/347-minor-ecce-oddity-when-pasting.html

* Long lines in xterm/csh
xterm -f (invoked by alt+l) on a running calculation doesn't work is the resulting command is longer than 256 characters. e.g.
xterm -title "optimization_def2svp_boat_acetonitrile_to_start_again_g09_pcm_ts-1" -bg "#b7b8ba" -fg "#000000" -sb -geom 80x40 -e tail -f /home/calc/boron/testing/testing/catalyst/optimization_def2svp_boat_acetonitrile_to_start_again_g09_pcm_ts-1/g03.g03out

which has 257 characters doesn't work when used by ECCE (which uses (t)csh), but works fine in bash.


* Rounding in ECCE when using Coefficients and Exponents. 
NOTE: this is fixed in ECCE 7.0

When you select a bass set in ECCE you can either represent it as
basis Be library '6-31g' end
or you can check the 'Use Exponents and Coefficients' in the ECCE Editor. If you check that box you'll get something like this instead:
basis "ao basis" cartesian print Be S 1264.58570000 0.00194500 189.93681000 0.01483500 43.15908900 0.07209100 12.09866300 0.23715400 3.80632300 0.46919900 1.27289000 0.35652000 [..]
However, the 6-31G.BAS file gives the coefficients and exponents as
atom=Be contraction shell=S num_primitives=6 num_coefficients=1 1264.5857 0.0019448 189.93681 0.0148351 43.159089 0.0720906 12.098663 0.2371542 3.8063232 0.4691987 1.2728903 0.3565202
Note the higher precision (there are more extreme examples, but this one will do for demonstration).
Finally, if you define the basis set using the * library '6-31g' way, you get
Be (Beryllium) -------------- Exponent Coefficients -------------- --------------------------------------------------------- 1 S 1.26458570E+03 0.001945 1 S 1.89936810E+02 0.014835 1 S 4.31590890E+01 0.072091 1 S 1.20986630E+01 0.237154 1 S 3.80632320E+00 0.469199 1 S 1.27289030E+00 0.356520 2 S 3.19646310E+00 -0.112649 2 S 7.47813300E-01 -0.229506 2 S 2.19966300E-01 1.186917

In other words, you get somewhat different precision depending on how you use a basis set (3.8063232 vs 3.806323). Not a major issue, but it's still somewhat odd behaviour. The issue is much more significant when I use the def2 basis sets.

In terms of the energy at b3lyp/6-31g for an isolated Be atom I get this with Coeffs/Exps:
Total DFT energy = -14.668063062134 One electron energy = -19.130485660973 Coulomb energy = 7.245896594547 Exchange-Corr. energy = -2.783473995707 Nuclear repulsion energy = 0.000000000000 Numeric. integr. density = 3.999999797518 Total iterative time = 0.2s
vs this with Be library '6-31g'
Total DFT energy = -14.668063028950 One electron energy = -19.130484712269 Coulomb energy = 7.245894834880 Exchange-Corr. energy = -2.783473151561 Nuclear repulsion energy = 0.000000000000 Numeric. integr. density = 3.999999797514 Total iterative time = 0.2s


2. Features
* A script for importing/adding new basis sets, as they become supported by nwchem. I've started work on this but I'm stuck without understanding why. See part 1 here: http://verahill.blogspot.com.au/2013/06/455-adding-nwchem-basis-sets-to-ecce.html

DONE!
http://verahill.blogspot.com.au/2013/06/456-adding-nwchem-basis-sets-to-ecce.html
https://sourceforge.net/projects/nwbas2ecce/ !

Note: the source distribution of ECCE 7.0 will contain a few helper scripts for importing basis sets.

* More options when setting up COSMO calculations. Currently you can set the dielectric constant, but nothing else. being able to set at a minimum rsolv and iscren would be welcome.

NOTE: this is fixed in ECCE 7.0

* Better Gaussian input/output support. This will by necessity have to be produced by someone outside PNNL as they are banned from receiving a license for Gaussian (they are considered competitors owing to the development of nwchem).

* Adding support for more computational packages, especially GAMESS US and Dalton (since they are free/open source).

* Updated documentation/more examples in documentation. The easiest solution is having more people blogging about what they are doing -- and HOW they are doing it.

3. Other
* I'd like to see ECCE included in e.g. Debian (assuming that the license is acceptable and that EMSL/PNNL allow it+). However, not only am I not proficient in making canonical debian packages, the build script for ECCE is a bit more advanced than the usual configure/make/make install ones. So it'll take someone with a bit more expertise than myself.

+one issue is that funding is often tied to being able to demonstrate that a piece of software is being used. And the easiest way to show that it's used is to retain control over downloads/encouraging people to register.

12 June 2013

448. Metal-pi bonds in ECCE

It should be easy, since it's one of the implemented bond types in ECCE together with single, double, triple and pi-arene bonds, but it doesn't function quite as advertised (supposed to ignore nubs).

I think it might be a bug, but given the very few resources currently given to ECCE, it's better to develop work-arounds than to demand quick bug fixes.

A reasonable criticism of this post would be that it really doesn't matter in the long run though, as the bonds that we make here are eye-candy only -- DFT doesn't 'know' what bonds are in the sense of the ball-and-stick model. On the other hand, ECCE will complain loudly if there's a discrepancy between oxidation states, multiplicity and number of vacant sites.

In the end, if you have a crystal structure to start from, use that. If not, then this is a fairly simple way of yielding a visually pleasing and reasonably intuitive model.

Anyway, let's use Noyori's catalyst as an example:


Start ECCE, set up a new job and click on Builder.

Click on Import from Structure Library, select Alicycles, and click on Cyclooctane, then click in the main window.


Delete one hydrogen on each of the sp2 carbons, and change the bond type to double bond:

 Change the sp2 carbons to TrigonalPlanar, and Clean (click the broom which does MM (UFF) geometry optimization).

Insert an octahedral iridium atom -- you'll need two 'nubs' for each pi bond, and two nubs for the two phosphine ligands.

 Change the sp2 carbons back to tetrahedral so you get 'nubs' to bond to (not supposed to be necessary according to the manual, but it is). Make Metal-pi bonds.
 Make sure all the bonds (check the first one in particular) are Metal-Pi bonds, and Clean the structure (i.e. MM/UFF optimization)


 Insert two tetrahedral phosphorous atoms, and make single bonds
Click on Add H if you want PH3 ligands, and clean the structure (i.e. optimize geo with MM/UFF):


At this point the structure isn't quite perfectly square planar like we would like it to be. The easiest way to sort that out is to set the torsional angles between the H-C(=)-Ir-P to 0 (uncheck rotate group around bond) for each P, then Clean. The result isn't perfect, but still not too shabby: