-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange error reading Gaussian frequencies #19
Comments
I think overall that part of the code needs to be reworked. It is specific to regular freq calculations.
|
We'll need to discuss through what is what here. Number 2 first: The combination of eigenvectors and eigenvalues is the SAME information that is found in the Hessian, true, but it has been pruned to remove the rotations and translations. And using these allows us more precise error analysis. We'll discuss other ways of using the Hessian, but for now, the eigenvectors should be the preferred way. |
Still haven't done any of my frequencies using Gaussian, so I managed to overlook this. I quick fixed the "Haromic" typo in 9a735d2. Not sure how to work around "unusual" frequency files because I don't have any to work with. Could you send me some examples? Also, it'd be nice if we could use the archive Hessian (it's a convenient way to ensure that the coordinates are in the right orientation) and project out the rotations and translations ourselves, but that's quite the project. :) |
I’ll look up a couple and send you. The problem: we must recognize two different types of lines with numeric values, while recognizing when the blocks start and end without crashing. The number of lines in between is variable, and I don’t know any text we can trust will always appear in the right place. Sounds like a problem for the re module, but I’d need to learn more. Keywords to Freq that cause unusual output include HPModes (which gives two sets of output, and we should only use the high-precision one) and Projected (reduces the number of eigenvectors and changes the headings). The problem in Macc came when David used “Projected”. We ARE using the archive now, aren’t we? Yes, we could project and diagonalize ourselves, looked into it a bit, but as you say, quite a project, and Gaussian has done it all for us already, that’s why I prefer to use it directly. I did look into what would be needed, defining the translation (easy) and rotation (harder) vectors, then do a Gram-Schmidt ortogonalization: https://en.wikipedia.org/wiki/Gram%E2%80%93Schmidt_process I preferred not to do that… BTW, more info here: http://www.gaussian.com/g_whitepap/vib.htm /Per-Ola From: Eric Hansen [mailto:notifications@github.com] Still haven't done any of my frequencies using Gaussian, so I managed to overlook this. I quick fixed the "Haromic" typo in 9a735d29a735d2. Not sure how to work around "unusual" frequency files because I don't have any to work with. Could you send me some examples? Also, it'd be nice if we could use the archive Hessian (it's a convenient way to ensure that the coordinates are in the right orientation) and project out the rotations and translations ourselves, but that's quite the project. :) — Confidentiality Notice: This message is private and may contain confidential and proprietary information. If you have received this message in error, please notify us and remove it from your system and note that you must not copy, distribute or take any action in reliance on it. Any unauthorized use or disclosure of the contents of this message is not permitted and may be unlawful. |
I know the formchk files contain the Hessian, but does anyone know if they also have the eigenvectors? I've been trying to see what information we could get out of the formchk file. It might be a better alternative to the *.log files. |
We initially used the formcheck files. Same data as in the archive, but a different orientation... And not the eigenvectors. At last when we use the archive, we can find all the information in one file. /Per-Ola From: arosale4 [mailto:notifications@github.com] I know the formchk files contain the Hessian, but does anyone know if they also have the eigenvectors? I've been trying to see what information we could get out of the formchk file. It might be a better alternative to the *.log files. — Confidentiality Notice: This message is private and may contain confidential and proprietary information. If you have received this message in error, please notify us and remove it from your system and note that you must not copy, distribute or take any action in reliance on it. Any unauthorized use or disclosure of the contents of this message is not permitted and may be unlawful. |
One file with normal, low precision modes, two files with HPModes, the first one works, the second one not (due to the extra keyword "Projected"). I believe the low-precision modes are identical in all three files, and they give different results when applied to the same .mae using -mgeig , so that's good, the program seems to pick up the high precision modes when available. Seems the only thing left to solve is the inability to pick up the modes from the third file, and it's not urgent. |
Tone down later. Reference issue #19.
Using the projected keyword in Gaussian seems to add in an additional line that includes the key phrase "IRC Coupling". This was throwing off the reading of the eigenvectors. I believe that adding the simple checks for that key phrase and skipping that line if present seems to have fixed the issue. Also commented out a lot of logging. Still could use more testing. Reference issue #19.
Originally, all the code in filetypes for Gaussian logs came from the original Python Q2MM code. I had never rewritten this part before. Now, it's all cleaned up. Looks pretty good, no? Closes issue #19.
Error when reading Gaussian files with HPModes frequencies. filetypes.py checks for the presence of "Haromic" two places, obvious misspelling. Does this mean no one has used the HPModes keyword? We should. Also, seems to fail un "unusual" Frequency files, for example when the keyword "Projected" has been used. The lines before the actual eigenvectors seem variable, how to handle?
The text was updated successfully, but these errors were encountered: