Incorrectly gives all real frequencies for a transition state

Hello all,

I think I came across a possible bug when computing the frequencies for a transition state structure. I have been looking at propanol, and computed the rotation curve for the CCCO torsion. From this curve, I know that the 120 degree structure corresponds to a transition state. I was able to do a full HF/6-31G(d) ts optimization of this structure to a gau_tight convergence. However, when I compute the frequencies, the output gives all real vibrations.

I did the calculation also in Gamess. Gamess correctly gives an imaginary frequency of 150 cm-1, with the remaining 29 vibrations being real. The optimized geometry from both programs overlay perfectly with each other.

Here is the input for the frequency in question:

memory 20 Gb

molecule molecule_09_psi {
0 1
        C           -1.796693182882    -0.190279729764     0.518349683495
        H           -1.779505625611    -0.377231131957     1.588722182623
        H           -1.824989286660    -1.151660791663     0.013997839699
        H           -2.720253868707     0.332537130381     0.290946953901
        C            0.758106399453    -0.074782432228     0.350857574786
        H            0.590317114783    -1.032813030656     0.839628736212
        H            1.371742112088     0.523936154656     1.020290511431
        O            1.425569079665    -0.269001191326    -0.872480357084
        H            2.255489284866    -0.696675615988    -0.715016088603
        C           -0.580986870203     0.623475378501     0.074709907639
        H           -0.633186532190     0.809367653635    -0.991774238933
        H           -0.600442968420     1.594218980334     0.561040527776

set globals {
      reference rhf
      opt_type ts
      basis 6-31G(d)

Psi4 version Information:
Psi4 1.1a2.dev170
Git: Rev {master} e4fcd91 dirty

All the bests,

This example may interest you, @Rollin_King. Don’t suppose there’s any way to verify TS-ness before the freq job.

@Karl, could you send the grep '~' output.dat of your output, the final “optimized” geometry, and the list of obtained freqs? Thanks!

Hi Lori,

I have attached the frequency (molecule-09-psi-f.inp.dat) output file, which also contains the list of obtained frequencies, and the optimized geometry (molecule-09-psi.inp.log.txt) in xyz format.

I’m not sure about verifying the TS-ness of a geometry, but I can predict quite accurately what geometry should be at least a single saddle point. I do this by computing torsion rotational curves. From experience, when I constrain a single torsion angle at sequential degrees, and the rest of the molecule does not undergo significant geometric changes (i.e. I generate a continuous energetic rotational curve), then the resulting local maxima a always a transition state if I perform a full relaxed transition state optimization. The attached data is coming from a TS optimization using gau_tight; however, I have also reproduced these results using gau_verytight geometry.

I have attached the rotational curve that identified the TS in question. Granted the degree sampling is sparse at 30 degrees, but I also know that is good enough for molecules that have sp3 hybridization. As you can see in the curve, 0 and 120 degrees should be TS. (Just as a side note - this curve was made using Gamess instead of Psi4. I am still having problems getting Psi4 to perform these constraint optimization without giving various errors on various inputs. With some individual input file manipulations I can get Psi4 to generate these curves. However, with Gamess I will reliably obtain optimized results using my workflow, without spending time playing around with keywords.)

I will also note that I have done these types of calculations several times using Psi4, and this is the first and only time that I have encountered this issue.

Please let me know if there is anything else that I can clarify or provide (perhaps the Gamess output?).

All the bests,

Attached molecule-09-psi.inp.log.txt (819 Bytes)
molecule-09-psi-f.inp.dat (53.9 KB)

Hi, Karl. Thanks a lot for the detailed bug report. I’m 99% sure that I’m to blame here. The code that figures out the displacements and does the numerical differentiation is what also performs the frequency analysis. This is bad design, because it means the code that I recently added to do analytic Hessians doesn’t have access to the analysis code (we’re working to fix that). In the mean time I coded up a simple hack to find the frequencies, but my primitive method for removing translations and rotations is obviously not working. I’ll look into this and try to get a fix worked out. Sorry for the inconvenience.

As a stopgap, you can add freq(…, dertype=1). That’ll do finite difference freq, which vib analysis can handle TS. Our apologies, and thanks for all the info.

Hi Andy and Lori,

No need to apologize or to be sorry…I am just excited that I could contribute some to improving the code. I think Psi4 is fantastic and promote it when I have the opportunity.

All the bests,