“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.

2015jan1_Mode17_Wrong_Raman_Activity

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).

Dipole Derivative, Polarizability Derivative, And Vibrational Polarizability Contribution Output From Gaussian09 With IOp(7/33)

For those itching for polarizability derivative orientation information and wondering where it is when you ask for it… what’s included below is a combination of a few points in one, specifically pointing out that the IOp options are not just “another part” of the Gaussian input file (with the IOp Overlays currently linked HERE).

The problem I realized after an email from Gaussian HQ was that, as was the case for the KMLYP density functional call discussed in previous posts about [18]-annulene, “opt” and “freq” keyword combinations are seen as two distinct runs in Gaussian that don’t pass the IOp information along (and, admittedly, I should have remembered that). Specifically, the additional print-out for the polarizability info is called by IOp(7/33=3).

What I provide below is a two-in-one input file that saves you from having to run double-duty input files in the checkpoint file. This also serves as a template for those looking for examples of combining multi-step input files that include mixed basis sets (as many of the problems I’ve been emailed stem from carriage return issues more than anything else). Note that the input file is set to run Raman intensities and produce higher-precision (hpmodes) eigenvectors (so, if you just want to test this, remove the “raman”).

%chk=C4H5Cl_B3LYP_631Gdp_LanL2DZ_IR_Raman.chk
#p scf=tight opt=tight b3lyp/GEN pseudo=read

C4H5Cl_B3LYP_631Gdp_LanL2DZ_IR_Raman Opt

0 1
 C                 -1.74671095   -0.64168298    0.00000000
 H                 -1.53944096   -1.69141587    0.00000000
 C                 -0.73010315    0.25446188    0.00000000
 H                 -0.93737314    1.30419477    0.00000000
 C                  0.73010315   -0.25446188    0.00000000
 H                  0.93737314   -1.30419477    0.00000000
 C                  1.74671095    0.64168298    0.00000000
 H                  1.53944096    1.69141587    0.00000000
 H                 -3.73526840    0.03531673    0.00000000
 Cl                 3.73526840   -0.03531673    0.00000000

C H 0
6-31G(d,p)
****
Cl
Lanl2DZ
****

Cl
Lanl2DZ

--Link1--
%chk=C4H5Cl_B3LYP_631Gdp_LanL2DZ_IR_Raman.chk
#p Geom=Check Guess=Read freq(raman,hpmodes) iop(7/33=3)
 
C4H5Cl_B3LYP_631Gdp_LanL2DZ_IR_Raman Freq
     
0 1

Note the carriage return after the second “0 1”.

For the demo molecule above, additional print-out below.

 Dipole derivatives wrt mode   1:  3.96988D-14 -1.15747D-14 -1.96904D-01
 Polarizability derivatives wrt mode          1
                 1             2             3 
      1   0.000000D+00  0.000000D+00  0.206435D+00
      2   0.000000D+00  0.000000D+00  0.143916D-01
      3   0.206435D+00  0.143916D-01  0.000000D+00
 Vibrational polarizability contributions from mode   1       0.0000000       0.0000000       0.0257731
 IFr=  0 A012= 0.23D-23 0.77D+00 0.13D+00 Act= 0.90D+00 DepolP= 0.75D+00 DepolU= 0.86D+00

Alternately, keep track of the checkpoint file.