Strange error reading Gaussian frequencies about q2mm HOT 7 CLOSED

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?

from q2mm.

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

from q2mm.

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

from q2mm.

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:[email protected]]
Sent: den 27 maj 2016 20:42
To: ericchansen/q2mm [email protected]
Cc: Norrby, Per-Ola [email protected]; Author [email protected]
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.

from q2mm.

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.

from q2mm.

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:[email protected]]
Sent: den 30 maj 2016 10:06
To: ericchansen/q2mm [email protected]
Cc: Norrby, Per-Ola [email protected]; Author [email protected]
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.

from q2mm.

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

from q2mm.