The orientation of Gaussian grads is differ from that of Gaussian atomcoords.

For grads parsed data for Gaussian, input orientation is used, although standard orientation is used for other data including atomcoods and vibdisps. This is becauses that Gaussian outputs gradient with input orientation and other values with standard orientatoin. Since parsed data for Gaussian doesn’t contain atom coordinates with input oriea or rotation matrix to convert input orientation to standard orientation, we can’t convert parsed grads from input orientation to standard orientation.

I think there are two choices to resolve this problem.

1. Convert grads to standared orientation inside cclib
2. Add input orietation atom coordinates or rotation matrix to parsed data, so that user can convert grads from input orientation to standard orientation.

Which option do you prefer? I think 1. is better choice althogh it does’nt maintain backwaord compatibiilty.

I put atomcoords and grads pased from test data with cclib. You can find that orientation for grads is differ from that for atomcoords.

In [2]:
d = cclib.io.ccread("../data/Gaussian/basicGaussian09/dvb_gopt.out")
print(d.atomcoords[0])
[[ 1.205666e+00  6.768910e-01  0.000000e+00]
 [ 2.200000e-03  1.375535e+00  0.000000e+00]
 [-1.205666e+00  6.892860e-01  0.000000e+00]
 [-1.205666e+00 -6.768910e-01  0.000000e+00]
 [-2.200000e-03 -1.375535e+00  0.000000e+00]
 [ 6.730000e-03  2.470443e+00  0.000000e+00]
 [-2.150459e+00  1.244759e+00  0.000000e+00]
 [-6.730000e-03 -2.470443e+00  0.000000e+00]
 [-2.492798e+00 -1.419218e+00  0.000000e+00]
 [-2.577785e+00 -2.759452e+00  0.000000e+00]
 [-1.654345e+00 -3.363669e+00  0.000000e+00]
 [-3.397785e+00 -7.969190e-01  0.000000e+00]
 [-3.516212e+00 -3.273509e+00  0.000000e+00]
 [ 2.492798e+00  1.419218e+00  0.000000e+00]
 [ 3.397785e+00  7.969190e-01  0.000000e+00]
 [ 2.577785e+00  2.759452e+00  0.000000e+00]
 [ 1.654345e+00  3.363669e+00  0.000000e+00]
 [ 3.516212e+00  3.273509e+00  0.000000e+00]
 [ 1.205666e+00 -6.892860e-01  0.000000e+00]
 [ 2.150459e+00 -1.244759e+00  0.000000e+00]]

In [3]:
print(d.grads[0])
[[-0.05044906  0.          0.0006004 ]
 [-0.00722221  0.          0.0239222 ]
 [-0.03871192  0.          0.02960709]
 [ 0.05044906  0.         -0.0006004 ]
 [ 0.00722221  0.         -0.0239222 ]
 [ 0.00108782  0.          0.00136294]
 [ 0.00068463  0.          0.00135426]
 [-0.00108782  0.         -0.00136294]
 [ 0.01037156  0.          0.0028839 ]
 [-0.01923258  0.         -0.01367979]
 [ 0.00632887  0.          0.00841993]
 [ 0.00120737  0.          0.00128327]
 [ 0.01947715  0.          0.0103679 ]
 [-0.01037156  0.         -0.0028839 ]
 [-0.00120737  0.         -0.00128327]
 [ 0.01923258  0.          0.01367979]
 [-0.00632887  0.         -0.00841993]
 [-0.01947715  0.         -0.0103679 ]
 [ 0.03871192  0.         -0.02960709]
 [-0.00068463  0.         -0.00135426]] ```

[berquist]

I think I misunderstood the severity of the situation. I did calculations with Gaussian, Q-Chem, Psi4, GAMESS, and DALTON, and only Gaussian rotates the gradient back into the input orientation. All the others print the gradient for the rotated coordinates.

From http://gaussian.com/force/,

The forces are determined in the standard orientation, but are restored to the original (Z-matrix) set of axes before printing (as noted in the output). This is followed by the corresponding derivatives with respect to the internal coordinates (lengths and angles used in the Z-matrix) when internal coordinates are in use. The forces are followed in each case by their maximum and root-mean-square values.

So, this only appears with Gaussian, unless another program I haven’t tested does the same thing.

I think I agree that this is a bug and am fine with changing the default, and not having this behind a flag, though I am troubled by how the Gaussian output is different from general output.

[cks-coil]

Thanks for the comment. My option 1 should be as follow:

1. convert grads to the orientation of atomcoords

In the case “input orientaion” is used for the calculation (e.g. “standared orientaion” coordinate doesn’t exists on logfile), parsed atomcoords and grads are coordinates / values in input orientaion, and we should not convert grads to other orientaion. (If we turn off symmetry, “input orientaion” is used) In the case “standard orientaion” is used for the calculation, parsed atomcoords is coordinates in “standared orientaion”, and parsed grads is in “input orientation”. Therefore, we should convert grads to “standared orientaion”.

It would not be affect programs which parse symmetery turned off results, or use L2 norm of grads calculated with symmetry. And it only affects programs which used x,y,z values of grads calculated with symmetry. There would be three cases for affected programs.

A. Use own forked branch of cclib ( convert grads or keep “input orientaion” coordiates in parse data) B. Use extarnal program to obtain “input orientaion” coordinates. C. Use atomcoords and grads parsed by cclib (this program has a bug) ( I was case C, and currently I’m case A )

There would be no or only few programs/uses in case B, and more programs/users is/well be in case C, I think. And I think “1. convert grads to the orientation of atomcoords” should be default and add flags or warnings for case B programs/users would be better.

How dou you think?