Hi all.
I hesitated submitting this as a bug, but it should be OK on
the devel list, since the subject matter is still experimental.
First, viewing intermediate optimization geometries in
Avogadro is a great addition. But, here is the problem.
I first checked conformer viewing using the supplied test
file edos.g03. It looks fine, six steps displayed.
Then tried a file of mine : the conformer list contains
9 entries, 5 of which with E=0 (5 iterations in opt).
Greping around those files, I found that edos.g03 contains
only “Input orientation” coordinates. Mine contains both
Input and Standard orientation. Using terse output, it
contains only “Standard orientation”. Could not find a
way to produce a file with only Input entries.
I finally realized that the first atom coordinate in edos.g03
strangely looks like a duplicate “charge multiplicity” card.
Removing it from the coordinates list produces a normal
output. This is a strange Gaussian-E01 bug that allows
an atom of type 0!
But with a correct file, Input or Standard orientation should
be displayed. My preference would go to Standard, but
up to you to decide. And all steps should be displayed:
7 for edos.g03.
Finally, what are the units for the energy values?
I expected A.U., but it decidedly is not.
Greetings,
Louis
Hi.
My previous message has so far received no attention.
No harm.
Recent trunk updates make it possible to display Gaussian
optimization steps in Avo. Great addition.
The problem is that the test file is in error.
OB gaussformat should be searching for “Standard orientation”,
not “Coordinates”: this will result in duplicate entries from
"Input orientation" and “Standard orientation”. And experienced
users may use terse output (#t …), that will produce files with
no standard input entries.
This trivial modification of OB gaussformat produces desired
output:
"// else if(strstr(buffer,“Coordinates (Angstroms)”) != NULL)
else if(strstr(buffer,“Standard orientation:”) != NULL)
{
numTranslationVectors = 0; // ignore old translationVectors
ifs.getline(buffer,BUFF_SIZE); // ---------------
ifs.getline(buffer,BUFF_SIZE); // column headings"
But I am still faced with the units problem.
Users that will use this functionality will probably expect
Hartree’s. Values displayed in “Conformers” are almost
Joules/mol. Unless my computer is producing wrong
values, I really do not grep how these energy values are
computed, nor what are their units.
I would greatly appreciate if anyone can explain this
point to me.
Cheers,
Louis
On Mar 4, 2010, at 2:42 PM, Louis Ricard wrote:
This trivial modification of OB gaussformat produces desired
output:
Thanks. As I said, I didn’t have much time to debug – still don’t. But I’ll make the suggested modification, it’s much appreciated.
Users that will use this functionality will probably expect
Hartree’s.
The key problem is that this functionality is used by multiple types of uses. Conformers in MM methods are in kJ/mol or kcal/mol. In Avogadro, I’ve standardized the energies into kJ/mol – the SI unit. In Open Babel, everything is supposed to be in kcal/mol.
So the critical point is that any “geometry optimization” extension should really handle energy conversion from kcal/mol into Hartree. Annulen suggested support for energy units in OB, which is OK too.
-Geoff
I can understand that.
But part of my confusion was that I was unable to check values
generated by Avo Conformers:values calculated from A.U. energies
were close to but slightly smaller than those displayed.
This comes from the value of KCAL_TO_KJ in OB (4.1868)
while we usually use 4.184 as recommended in the Gaussian manual
(http://www.gaussian.com/g_tech/g_ur/k_constants.htm).
I do not know what value is used by other major QM programs.
And what guided your choice in OB.
Louis
Geoffrey Hutchison a écrit :
The key problem is that this functionality is used by multiple types of uses. Conformers in MM methods are in kJ/mol or kcal/mol. In Avogadro, I’ve standardized the energies into kJ/mol – the SI unit. In Open Babel, everything is supposed to be in kcal/mol.
So the critical point is that any “geometry optimization” extension should really handle energy conversion from kcal/mol into Hartree. Annulen suggested support for energy units in OB, which is OK too.
05.03.10, 11:29, “Louis Ricard” louis.ricard@polytechnique.edu:
I can understand that.
But part of my confusion was that I was unable to check values
generated by Avo Conformers:values calculated from A.U. energies
were close to but slightly smaller than those displayed.
This comes from the value of KCAL_TO_KJ in OB (4.1868)
while we usually use 4.184 as recommended in the Gaussian manual
(http://www.gaussian.com/g_tech/g_ur/k_constants.htm).
I do not know what value is used by other major QM programs.
And what guided your choice in OB.
I think Gaussian is not an organization like IUPAC to introduce standards for unit definitions. However, according to Wikipedia, the first calorie (4.1868) is International Steam Table calorie, the second (4.184) is Thermochemical calorie, approved by ISO, so I think 4.184 is more relevant for conformers energies. Just my $0.02
–
Regards,
Konstantin
I think Gaussian is not an organization like IUPAC to introduce standards
for unit definitions. However, according to Wikipedia, the first calorie
(4.1868) is International Steam Table calorie, the second (4.184) is
Thermochemical calorie, approved by ISO, so I think 4.184 is more relevant
for conformers energies. Just my $0.02
Gaussian sure isn’t trying to introduce standards. I’m sure they just used the
thermochemical definition, which is the only one have ever seen used, too…
Regards
X. W.
Xaver Wurzenberger a écrit :
I think Gaussian is not an organization like IUPAC to introduce standards
for unit definitions. However, according to Wikipedia, the first calorie
(4.1868) is International Steam Table calorie, the second (4.184) is
Thermochemical calorie, approved by ISO, so I think 4.184 is more relevant
for conformers energies. Just my $0.02
Gaussian sure isn’t trying to introduce standards. I’m sure they just used the
thermochemical definition, which is the only one have ever seen used, too…
Regards
X. W.
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
Agreed. In fact they cite this publication:
Rev. Mod. Phys. 80, 633 (2008) - CODATA recommended values of the fundamental physical constants: 2006
L.
Le 4 mars 2010 à 22:28, Geoffrey Hutchison a écrit :
On Mar 4, 2010, at 2:42 PM, Louis Ricard wrote:
This trivial modification of OB gaussformat produces desired
output:
This really was a rather naive solution.
In the meantime, I had to read the Gaussian manual and found
that the situation is more complicated.
Due to various options in the Gaussian route card, I spotted
four different situations:
-
normal or verbose output (“# some functional … opt” or
“#p … opt”); this produces output containing both input and
standard input coordinates.
-
a route like “#t … opt” will give output that contains only
standard orientations.
-
specifying “nosym” in the route section will result in an
output that contains only input orientations.
4)using both terse (#t) and nosymm yields a file with no
intermediate coordinates: forget this one, we can do nothing
about it.
Since we do not know what is being read, I propose
using “Input orientation” as default and “Standard
orientation” otherwise. Hence the attached patch to
OB gaussformat.cpp.
This was only tested with g03.
Regards,
Louis
On Mar 6, 2010, at 2:50 PM, Louis Ricard wrote:
This was only tested with g03.
This seems to work fine with g09 as well. Sorry for the delay, it’s now in OpenBabel SVN and will be part of the next beta “snapshot.”
Thanks very much,
-Geoff