The orientation of Gaussian grads is differ from that of Gaussian atomcoords.
See original GitHub issueFor 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.
- Convert
grads
to standared orientation inside cclib - 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]] ```
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (5 by maintainers)
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/,
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.
Thanks for the comment. My option 1 should be as follow:
grads
to the orientation ofatomcoords
In the case “input orientaion” is used for the calculation (e.g. “standared orientaion” coordinate doesn’t exists on logfile), parsed
atomcoords
andgrads
are coordinates / values in input orientaion, and we should not convertgrads
to other orientaion. (If we turn off symmetry, “input orientaion” is used) In the case “standard orientaion” is used for the calculation, parsedatomcoords
is coordinates in “standared orientaion”, and parsedgrads
is in “input orientation”. Therefore, we should convertgrads
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 ofgrads
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. Useatomcoords
andgrads
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 ofatomcoords
” should be default and add flags or warnings for case B programs/users would be better.How dou you think?