CCSD(T) and MP4 Z-Matrix Coordinate Oddity In Gaussian: When In Doubt, Change Your Format

This post was instigated by Syracuse University Professor of Chemistry and well-known non-blogger Tim Korter concerning efforts to, I believe, generate proper Møller-Plesset Perturbation Theory Of The 4th Order (MP4, and also testing coupled cluster CCSD(T) calculations) intermolecular potentials for improving terms for Grimme dispersion-corrected density functional theory (DFT) calculations with the Gaussian09 package (a program for which many people grumble about various issues but which is, by nearly all metrics, a fantastic set of quantum chemical programs). The examples below, using water only, are just for ease-of-testing, which produce the following results based on the form of the input of the molecular coordinates. For those wondering why, z-matrices are the preferred format for performing SCAN or other automated trajectory calculations (an absolutely useless format, in my opinion, now that we have computers that can handle more than five atoms).

1. Molecular coordinates defined in the z-matrix (obviously in z-matrix format) and "z-matrix" called in the opt keyword…

#p scf=tight opt(tight,z-matrix) MP4/aug-cc-pVTZ
 
h2o test 1
 
0 1
O              
H                  1    0.96000000
H                  1    0.96000000    2  109.50000032

… produces:

 ************************************************
 ** ERROR IN INITNF. NUMBER OF VARIABLES (  0) **
 **   INCORRECT (SHOULD BE BETWEEN 1 AND 50)   **
 ************************************************

2. Molecular coordinates defined in the z-matrix (obviously in z-matrix format) and "z-matrix" NOT called in the opt keyword…

#p scf=tight opt=tight MP4/aug-cc-pVTZ
 
h2o test 2
 
0 1
O              
H                  1    0.96000000
H                  1    0.96000000    2  109.50000032

… produces:

 ************************************************
 ** ERROR IN INITNF. NUMBER OF VARIABLES (  0) **
 **   INCORRECT (SHOULD BE BETWEEN 1 AND 50)   **
 ************************************************

3. Molecular coordinates defined by variables in the z-matrix (obviously in z-matrix format) and "z-matrix" called in the opt keyword…

#p scf=tight opt(tight,z-matrix) CCS(D)/aug-cc-pVTZ
 
h2o test 3
 
0 1
O              
H                  1    B1
H                  1    B1     2  A1 

B1 0.96000000    
A1 109.50000032

… produces:

Normal termination of Gaussian 09 at Fri Apr 27 11:28:33 2012.

4. Molecular coordinates defined by variables in the z-matrix (obviously in z-matrix format) and "z-matrix" NOT called in the opt keyword…

#p scf=tight opt=tight MP4/aug-cc-pVTZ
 
h2o test 4
 
0 1
O              
H                  1    B1
H                  1    B1     2  A1 

B1 0.96000000    
A1 109.50000032

… produces:

Normal termination of Gaussian 09 at Fri Apr 27 11:28:33 2012.

So, a solution, for when the dreaded…

 NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-NEF-
 NUMERICAL EIGENVECTOR FOLLOWING MINIMUM SEARCH
 INITIALIZATION PASS


 ************************************************
 ** ERROR IN INITNF. NUMBER OF VARIABLES (  0) **
 **   INCORRECT (SHOULD BE BETWEEN 1 AND 50)   **
 ************************************************

… error appears, the simple solution is to re-define your system.

In the interest of wasting a few cycles, I ran a series of the same calculations with other post-Hartree-Fock methods [B3LYP, MP2, MP4, CCS(D), CCSD(T)] to see how pervasive the issue with coordinate definitions might be. It appears to be limited only to MP4 and CCSDT (CCS(D) worked but took an unbelievably long time for Option 3 above), meaning people generally running significant molecules likely have never come across the issue.

/var/lib/ureadahead/debugfs And Disk Space "Recovery" In Ubuntu 10.04

And happy new year.

I had thought this was something involving Gaussian09 memory usage until I restarted a machine and found the same problem occurring in Ubuntu. Below is a quick fix (and reminder for the future).

Checking disk space with df -all :

user@machine:~$ df -all
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            147550696   5863896 134191632   5% /
proc                         0         0         0   -  /proc
none                         0         0         0   -  /sys
none                         0         0         0   -  /sys/fs/fuse/connections
none                         0         0         0   -  /sys/kernel/debug
none                         0         0         0   -  /sys/kernel/security
none                   3053752       260   3053492   1% /dev
none                         0         0         0   -  /dev/pts
none                   3058264         0   3058264   0% /dev/shm
none                   3058264        84   3058180   1% /var/run
none                   3058264         0   3058264   0% /var/lock
none                   3058264         0   3058264   0% /lib/init/rw
none                         0         0         0   -  /var/lib/ureadahead/debugfs
nfsd                         0         0         0   -  /proc/fs/nfsd
binfmt_misc                  0         0         0   -  /proc/sys/fs/binfmt_misc

… we find /var/lib/ureadahead/debugfs both existing but taking up no space to speak of. Several seconds later (after a reboot), we find the following…

user@machine:~$ df -all
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            147550696   5864268 134191260   5% /
proc                         0         0         0   -  /proc
none                         0         0         0   -  /sys
none                         0         0         0   -  /sys/fs/fuse/connections
none                         0         0         0   -  /sys/kernel/debug
none                         0         0         0   -  /sys/kernel/security
none                   3053752       260   3053492   1% /dev
none                         0         0         0   -  /dev/pts
none                   3058264         0   3058264   0% /dev/shm
none                   3058264        84   3058180   1% /var/run
none                   3058264         0   3058264   0% /var/lock
none                   3058264         0   3058264   0% /lib/init/rw
none                 147550696   5864268 134191260   5% /var/lib/ureadahead/debugfs
nfsd                         0         0         0   -  /proc/fs/nfsd
binfmt_misc                  0         0         0   -  /proc/sys/fs/binfmt_misc

Properly updated machines (as per below) both do not contain this /var/lib/ureadahead/debugfs directory and do not subsequently "blow up" and eat disk space (to date. This may not be the real problem, but disk space usage will increase to +60% and, to my mind, the machine will noticeably slow down).

Fix Steps:

sudo aptitude update
sudo aptitude upgrade

Update your 10.04. Some web pages report that the problem with /var/lib/ureadahead/debugfs is attributable to a bug in mountall (now fixed. See bugs.launchpad.net/ubuntu/+source/mountall/+bug/736512).

sudo mv /etc/init/ureadahead.conf /etc/init/ureadahead.conf.disable

If you do NOT perform this move, the machine restart will produce the same /var/lib/ureadahead/debugfs error above. Kudos to ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 for pointing this out.

sudo shutdown -r now

System restart, problem (for me, at least) solved.