From: Karol L. <kar...@gm...> - 2009-06-11 22:44:12
|
Hi Hugh, On Saturday 06 June 2009 14:13:01 Hugh Chaffey-Millar wrote: > That's probably reasonable, but the code only extracts internal > coordinates if these were given in the input file as a z-matrix, and if > this is the case, the "user" will know what they refer to. Returning > gradients in the context of the supplied z-matrix is particularly > important if the user wants to implement a custom geometry optimisation > strategy and, for example, freeze some bonds, project out some forces, > etc. If cclib were to only return the forces in terms of Cartesians, > then the programmer would need to somehow construct a matrix of > dX_i/dI_j, i.e. the matrix whose elements are the change of cartesian > coordinate X_i with respect to internal coordinate I_j, for each point > in the optimisation. > > In light of the fact that other packages only give cartesians it's > probably reasonable, in the name of uniformity to extract these from a > Gaussian file, but I believe forces in terms of the supplied z-matrix > are also important. I, for example, for my current research, need to > know the forces in terms of the z-matrix variables. > > If you want I can add code to extract the cartesians as well. Just let > me know. Also, if you have any other comments about my python coding > style or other suggestions regarding the way in which you'd like it to > be written, please feel free to pass them on. I've only been coding in > python for a few months. Could I also look over your code and input/output example? On a related note, cclib has a hessian property that should contain the force constants, but currently it's implemented only for Molpro. As Noel wrote, cclib doesn't understand Z-matrices and works only with cartesian coordinates. Before parsing energy derivatives or anything else in terms of internal coordinates, there would have to be some kind of generic support for them in cclib. Maybe a 'zmatrix' attribute or at least one containing bond/angle definitions. Z-matrix parsing and/or interconversion with cartesians would be useful... currently I do it on a regular basis with openbabel. If not parsed, perhaps a helper method could build and return the z-matrix via openbabel. For derived quantities like (second) derivatives, it will be harder to maintain clarity and consistency between outputs from various programs if we were to provide them potentially in both cartesian and internal coordinates. I would again suggest a helper method in this case that converts the standard cartesian form to internal coordinates, with a Z-matrix or atom ordering given as input. > As I may have mentioned, I will probably add support for a number of > other programs, such as GAMESS, NWChem and possibly VASP, at some point, > so obviously should do this in a style that is consistent with the rest > of cclib. We don't parse nwchem or VASP output files at the moment, so there is no parse to currently add code to for those programs. > On another matter, I noticed a broken link of the main page: in the > opening sentence "cclib is an open source library, written in Python" > the Python link is broken. :-) Thanks, typo fixed. Best, Karol -- written by Karol Langner Fri Jun 12 00:13:30 CEST 2009 |