Embarrassingly parallel frequency calculation misbehaving

1

I have a concern with the Embarrassingly parallel mode for calculating frequencies. The following file will calculate frequencies for water using a numerical hessian as well as generate the input files for the individual sow-reap process.

In principle, both methods should generate the same numerical hessian and the same harmonic frequencies, but I get something different

     symmetry    conventional  sow/reap   (fequencies)
     A1         1691.8476       1691.8474
     A1         3827.0203       3827.0203 
     B2         3932.8218       3533.7750

The B2 mode is different. The conventionally calculated B2 frequency is correct (by referencing an analogous G09 calculation). I have tried this with a few different levels of theory to yield a similar result. I think this may be a bug in the construction of the hessian.

Any suggestions?

Using Git: Rev {master} 77546d2 dirty by the way

memory 3000 mb
set_num_threads(2)

molecule water {
0 1
O
H 1 r1
H 1 r1 2 a1

r1 = 0.95
a1 = 104.0
}

set {
basis cc-pvdz
freeze_core true
}

optimize(‘ccsd(t)’, dertype=‘energy’)
frequencies(‘ccsd(t)’, dertype=‘energy’)
frequencies(‘ccsd(t)’, dertype=‘energy’, mode=‘sow’)

2

I got a chance to look at this:

  1. Confirmed this is reproducible with SCF.
  2. The Cs displaced energy is wrong in the sow/reap case.
  3. The Cs displaced geometry is wrong in the sow/reap case - it is (in error) C2v. Clearly, the displaced geometry is getting symmetrized.
  4. Realized the problem/bug appears in the use of the Z-matrix in the input file. PSI4 is trying to be intelligent by outputing the displaced geometry in the various input files in z-matrix format (since that is what you used initially). But the driver isn’t smart enough to reject your z-matrix format (with two equivalent bong lengths assigned to the variable r1) and construct a new one with two different bond lengths.

As an immediate fix for you, just run the distributed frequency calculation with a cartesian coordinate input, and it should work fine.

Someone needs to modify the sow code so that it alway outputs cartesian coordinates to the various input files regardless of the format of the initial input file.

3

sow/reap is due for a pass anyway to get it working after the wavefunction machinery pass, so I’ll fix this up then. Thanks, Rollin, for pinpointing the problem.

4

Thanks for the quick fix, I don’t know why I didn’t think of trying that…

5

Good news, when I took a look at this again after various other sow/reap updates, I found I had fixed this, too. So after https://github.com/psi4/psi4/pull/318 gets merged into the main branch, this misbehavior should be gone. Thanks for the report!