"OrtVc1 failed #1." Workaround In Gaussian09; Warning About (Pre-)Resonance Raman Spectra In GaussView 4/5

And Happy New Year.

Two issues (one easily addressable, one only by external workaround) related to the prediction of Raman intensities in Gaussian09 – for which there's next-to-nothing online to address either of them (likely because they don't come up that often).

OrtVc1 failed #1.

In simulating the Raman spectra of very long (> C60) polyenes as a continuance of work related to the infinite polyacetylene case (see this post for details: Bond Alternation In Infinite Periodic Polyacetylene: Dynamical Treatment Of The Anharmonic Potential), I reached a length and basis set for which Gaussian provides the following output and error:

...
 Minotr:  UHF open shell wavefunction.
          Direct CPHF calculation.
          Differentiating once with respect to electric field.
                with respect to dipole field.
          Electric field/nuclear overlap derivatives assumed to be zero.
          Using symmetry in CPHF.
          Requested convergence is 1.0D-08 RMS, and 1.0D-07 maximum.
          Secondary convergence is 1.0D-12 RMS, and 1.0D-12 maximum.
          NewPWx=F KeepS1=T KeepF1=T KeepIn=T MapXYZ=F SortEE=F KeepMc=T.
          MDV=    3932153962 using IRadAn=       1.
 Generate precomputed XC quadrature information.
          Solving linear equations simultaneously, MaxMat=      72.
          There are     3 degrees of freedom in the 1st order CPHF.  IDoFFX=0 NUNeed=     3.
      3 vectors produced by pass  0 Test12= 3.94D-11 3.33D-08 XBig12= 2.15D+05 2.71D+02.
 AX will form     3 AO Fock derivatives at one time.
 FoFJK:  IHMeth= 1 ICntrl=       0 DoSepK=F KAlg= 0 I1Cent=   0 FoldK=F
 IRaf= 160000000 NMat=   3 IRICut=       1 DoRegI=T DoRafI=F ISym2E=-1.
 FoFCou: FMM=T IPFlag=           0 FMFlag=      100000 FMFlg1=        2001
         NFxFlg=           0 DoJE=F BraDBF=F KetDBF=F FulRan=T
         wScrn=  0.000000 ICntrl=       0 IOpCl=  1 I1Cent=           0 NGrid=           0
         NMat0=    3 NMatS0=      3 NMatT0=    0 NMatD0=    3 NMtDS0=    0 NMtDT0=    0
 Petite list used in FoFCou.
 FMM levels:  10  Number of levels for PrismC:   9
      3 vectors produced by pass  1 Test12= 3.94D-11 3.33D-08 XBig12= 1.52D+04 3.94D+01.
      3 vectors produced by pass  2 Test12= 3.94D-11 3.33D-08 XBig12= 1.29D+04 3.31D+01.
      3 vectors produced by pass  3 Test12= 3.94D-11 3.33D-08 XBig12= 1.65D+06 4.27D+01.
      3 vectors produced by pass  4 Test12= 3.94D-11 3.33D-08 XBig12= 1.92D+08 6.96D+02.
      3 vectors produced by pass  5 Test12= 3.94D-11 3.33D-08 XBig12= 4.40D+10 7.74D+03.
      3 vectors produced by pass  6 Test12= 3.94D-11 3.33D-08 XBig12= 4.42D+12 1.70D+05.
      3 vectors produced by pass  7 Test12= 3.94D-11 3.33D-08 XBig12= 3.50D+14 1.14D+06.
      3 vectors produced by pass  8 Test12= 3.94D-11 3.33D-08 XBig12= 3.13D+16 1.34D+07.
      3 vectors produced by pass  9 Test12= 3.94D-11 3.33D-08 XBig12= 1.75D+18 4.02D+07.
      3 vectors produced by pass 10 Test12= 3.94D-11 3.33D-08 XBig12= 1.28D+20 7.81D+08.
      3 vectors produced by pass 11 Test12= 3.94D-11 3.33D-08 XBig12= 1.50D+22 7.70D+09.
      3 vectors produced by pass 12 Test12= 3.94D-11 3.33D-08 XBig12= 1.12D+24 5.57D+10.
      3 vectors produced by pass 13 Test12= 3.94D-11 3.33D-08 XBig12= 2.86D+25 5.87D+11.
 OrtVc1:  Ph=1 IOff=     0 IPass=20 DotMx1= 2.08D-06
 OrtVc1:  Ph=1 M=  1181528 NPass=20 Test1= 3.94D-11 Small= 1.18D-06 VSmall= 1.00D-12
 OrtVc1 failed #1.
 Error termination via Lnk1e in /opt/g09/l1002.exe at Sat Oct 11 01:10:22 2014.

What little there is available online for the "OrtVc1 failed #1." error (from CCL – here and here) is less than helpful in addressing the problem. The problem is also coordinate system-independent (Cartesian and z-matrix formats both provide the same error), but is sensitive to the choice of basis set (6-31G(d,p) would work fine through the Raman intensity predictions, 6-311G(2d,p) would fail at the stage above).

Directing the issue to Gaussian, the provided workaround is straightforward.

The prediction of Raman intensities requires using Coupled Perturbed Hartree-Fock (CPHF), for which a special sensitivity in the code (currently) exits when using both molecular symmetry and the fast multipole method, the use of which (FMM, that is) is governed by Gaussian09 based on the atom count.

The workaround, provided by Dr. Fernando Clemente at Gaussian, Inc., is to divide the calculation into two steps. My input for the first successful run is shown below. A few details:

1. The first stage contains no Raman keywords (just the plain "freq" call).

2. In the second stage, the cphf=rdfreq is reading an incident light frequency of 0 (cm-1 or nm) at the bottom of the input file ("0"). You can run the static or dynamic cases as you like at this stage.

3. Also in the second stage, FMM is turned off (nofmm).

4. Also still in the second stage, the option to calculate Raman intensities is turned on (polar=raman). This is, as it happens, a recommended way to perform Raman intensity calculations – run a typical normal mode analysis, then import the force constants (and geometry) from this calculation into a Link1 step while increasing the basis set size (for better intensity prediction).

%chk=checkpoint.chk
%nprocshared=12
%mem=50000MB
#p integral(grid=ultrafine) freq=hpmodes b3lyp/6-311++g(3df,3pd) scf=novaracc symm=loose

Part 1 - just the frequency calculation

0 1
 C                  0.00000000   48.56668920   -0.34496298
 C                  0.00000000   47.35252242    0.35603740
...
 H                  0.00000000  -49.50718415    0.19804614
 H                 -0.00000000   49.50718415    0.19804614
[blank line 1]
[blank line 2]
--link1--
%chk=checkpoint.chk
%nprocshared=12
%mem=50000MB
#p integral(grid=ultrafine) polar=raman cphf=rdfreq nofmm b3lyp/6-311++g(3df,3pd) geom=checkpoint

Part 2 - Raman intensities

0 1

0
[blank line 1]
[blank line 2]

In theory, your calculation should run just fine.

Raman Intensities And GaussView – Check Your .log File For Resonance

The next problem is GaussView-specific – one that only comes up when you've a system with dynamic polarizability (incredibly long polyenes being a prototypical example) or when you perform frequency-dependent Raman calculations and you slip near resonance.

When running a series of Raman intensity calculations with increasing incident light frequency (cphf=rdfreq, then an array of energies), Mode 17 of this particular molecule either has a really large activity (cannot be printed out) or we're approaching resonance (also a case of really large activity and it can't be printed out). This isn't a problem with the code, it's your molecule.

                     16                     17                     18
                     BG                     AG                     BG
 Frequencies --    218.8851               257.7857               266.9993
 Red. masses --      3.5318                 5.1372                 2.2022
 Frc consts  --      0.0997                 0.2011                 0.0925
 IR Inten    --      0.0000                 0.0000                 0.0000
 Raman Activ --      0.2046                 0.7412                 0.2871
 Depolar (P) --      0.7500                 0.3044                 0.7500
 Depolar (U) --      0.8571                 0.4667                 0.8571
 RamAct Fr= 1--      0.2046                 0.7412                 0.2871
  Dep-P Fr= 1--      0.7500                 0.3044                 0.7500
  Dep-U Fr= 1--      0.8571                 0.4667                 0.8571
...
 RamAct Fr=12--     90.1095           ************                 0.3406
  Dep-P Fr=12--      0.7500                 0.3333                 0.7500
  Dep-U Fr=12--      0.8571                 0.4999                 0.8571

This is all well-and-good if you only rely on the .log file. If you skip the .log file inspection and only ever use GaussView, the result of inspecting the Raman intensities is below.

Note that Mode 17 has the intensity of Mode 18, and Mode 18 has zero intensity. Something is afoot! If you know what to expect out of your system, the missing intensities should be obvious. If not, you're missing some very important information about your molecule.

The GaussView developers are aware of the problem. In the meantime, you can get around this problem by globally replacing all of the " ************ " (note the spaces on either side!) with a huge number (at which point the Raman intensity issue will become obvious – careful to preserve the spacing in the .log file).