Skip to content
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

Closed
peonor opened this issue May 26, 2016 · 7 comments
Closed

Strange error reading Gaussian frequencies #19

peonor opened this issue May 26, 2016 · 7 comments
Labels

Comments

@peonor
Copy link
Contributor

peonor commented May 26, 2016

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?

@arosale4
Copy link
Contributor

I think overall that part of the code needs to be reworked. It is specific to regular freq calculations.
Just some follow up questions:

  1. Why would we need higher precision eigenvectors? I mean I suppose we could try and parameterize to them, but my understanding is that they contain the same information as the eigenvalues.
  2. Do we need that part of the code anymore if we can just grab the Hessian from the archive?

@peonor
Copy link
Contributor Author

peonor commented May 27, 2016

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.
Question 1: have you looked at the absolute values? Sometimes below 0.01, meaning that contributions will completely disappear if you use the standard, low-precision numbers. I did some initial testing when we started using this, and there are significant differences, you get much lower off-diagonals when you multiply the eigenvectors onto the QM Hessian (where they theoretically should be exactly zero).

@ericchansen
Copy link
Owner

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. :)

@peonor
Copy link
Contributor Author

peonor commented May 30, 2016

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]
Sent: den 27 maj 2016 20:42
To: ericchansen/q2mm q2mm@noreply.github.com
Cc: Norrby, Per-Ola Per-Ola.Norrby@astrazeneca.com; Author author@noreply.github.com
Subject: Re: [ericchansen/q2mm] Strange error reading Gaussian frequencies (#19)

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. :)


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/19#issuecomment-222236450, or mute the threadhttps://github.com/notifications/unsubscribe/ANVSNEUBtYz2EeS60_6zF9PJdqpxcTFCks5qF0j9gaJpZM4InTxB.


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.

@arosale4
Copy link
Contributor

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.

@peonor
Copy link
Contributor Author

peonor commented May 30, 2016

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]
Sent: den 30 maj 2016 10:06
To: ericchansen/q2mm q2mm@noreply.github.com
Cc: Norrby, Per-Ola Per-Ola.Norrby@astrazeneca.com; Author author@noreply.github.com
Subject: Re: [ericchansen/q2mm] Strange error reading Gaussian frequencies (#19)

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.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/19#issuecomment-222447859, or mute the threadhttps://github.com/notifications/unsubscribe/ANVSNFTTn6tCgK5bo4bNxkINA95tiL_Pks5qGqiFgaJpZM4InTxB.


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.

@peonor
Copy link
Contributor Author

peonor commented May 31, 2016

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.

DistLPVib.txt
DistVib.txt
DistVibP.txt

ericchansen added a commit that referenced this issue Jul 7, 2016
Tone down later. Reference issue #19.
ericchansen added a commit that referenced this issue Jul 7, 2016
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.
ericchansen added a commit that referenced this issue Jul 8, 2016
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.
ericchansen pushed a commit that referenced this issue Aug 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants