Hi all.
I am pretty well confused.
While demoing OM’s display in Avo to one of our students, I realized
that something was wrong: symmetry was not there and after a while,
I realized that MO’s where somehow rotated relative to displayed
geometry. I then tried using a cube file (HOMO) and everything was O.K.
I then questioned my log and fchk file, reran the job, with no improvement.
In Windows GaussView, everything is correct.
Then gave a look at “coordinate editor”: enclosed file shows that there
definitely is a problem with OB: coordinates a mangled when reading
a Gaussian log file, not when reading a cube one.
I have similar behavior in my self compiled CentOS version, David’s
snapshot and MacOS 2010-11-10 nightly build.
Example com file attached so that you can tell me where is my error.
Regards,
Louis
Hi.
I have finally understood what all this coordinates business is.
Gaussian log files contain both XYZ and “Standard orientation”
coordinates while cubes and fchk files have only the Std ones.
So, no mangling, but a problem. In its current version, Avo will
read a gaussian log file using xyz coordinates and read the
associated fchk if it is present. Problem is that OM’s will be
rendered using a different set of coordinates, hence some queer
display of densities. If an fchk file is loaded, everything is OK.
A solution would be to systematically load std coordinates, but
this may also impact other functions, like vibrations animation
for instance.
Hope this can help,
Cheers,
Louis
Le 12 nov. 2010 à 21:04, Louis Ricard a écrit :
Hi all.
I am pretty well confused.
While demoing OM’s display in Avo to one of our students, I realized
that something was wrong: symmetry was not there and after a while,
I realized that MO’s where somehow rotated relative to displayed
geometry. I then tried using a cube file (HOMO) and everything was O.K.
I then questioned my log and fchk file, reran the job, with no improvement.
In Windows GaussView, everything is correct.
Then gave a look at “coordinate editor”: enclosed file shows that there
definitely is a problem with OB: coordinates a mangled when reading
a Gaussian log file, not when reading a cube one.
I have similar behavior in my self compiled CentOS version, David’s
snapshot and MacOS 2010-11-10 nightly build.
Example com file attached so that you can tell me where is my error.
Regards,
Louis
<coords.txt>
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
Hi,
may I add that there often is a third important set of coordinates: The Z-
Matrix.
GaussView itself often does not read the Z-Matrix if there are also xyz (or
std orientation?) coordinates available, but I have not quite understood when
it does. This is IMHO a bad idea as - for instance - dummy atoms are then
missing.
Regards,
Xaver
Am Samstag 13 November 2010, 10:04:47 schrieb Louis Ricard:
Hi.
I have finally understood what all this coordinates business is.
Gaussian log files contain both XYZ and “Standard orientation”
coordinates while cubes and fchk files have only the Std ones.
So, no mangling, but a problem. In its current version, Avo will
read a gaussian log file using xyz coordinates and read the
associated fchk if it is present. Problem is that OM’s will be
rendered using a different set of coordinates, hence some queer
display of densities. If an fchk file is loaded, everything is OK.
A solution would be to systematically load std coordinates, but
this may also impact other functions, like vibrations animation
for instance.
Hope this can help,
Cheers,
Louis
Le 12 nov. 2010 à 21:04, Louis Ricard a écrit :
Hi all.
I am pretty well confused.
While demoing OM’s display in Avo to one of our students, I realized
that something was wrong: symmetry was not there and after a while,
I realized that MO’s where somehow rotated relative to displayed
geometry. I then tried using a cube file (HOMO) and everything was O.K.
I then questioned my log and fchk file, reran the job, with no
improvement. In Windows GaussView, everything is correct.
Then gave a look at “coordinate editor”: enclosed file shows that there
definitely is a problem with OB: coordinates a mangled when reading
a Gaussian log file, not when reading a cube one.
I have similar behavior in my self compiled CentOS version, David’s
snapshot and MacOS 2010-11-10 nightly build.
Example com file attached so that you can tell me where is my error.
Regards,
Louis
<coords.txt>
----- Centralized Desktop Delivery: Dell and VMware Reference
Architecture Simplifying enterprise desktop deployment and management
using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev_____________________________________
__________ Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
— Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options