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

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.

The Cs displaced energy is wrong in the sow/reap case.

The Cs displaced geometry is wrong in the sow/reap case - it is (in error) C2v. Clearly, the displaced geometry is getting symmetrized.

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.

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.

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!