Einar Coutin wrote:
Well Bob, the thing is, the chemists I am working in this project with, are
using SPARTAN 02, they're planning on gettign 04 very soon. So far the only
thing we've done is exporting the SPARTAN 02 files to sybyl mol2..then
converting them with openbabel to .mol so Jmol can read them, anything else
is form molecules found in the repository...Of course I want to add
orbitals, vibrations, and even chemical reactions to those models, things
that I'm aware Jmol can do as of now.
You can read anything in the Spartan '04 files except the MOs. Perhaps
a bit of lobbying with Wavefunction would change that. It's worth a
try. Tell them I'll promise to put whatever warning message they want
(about future compatibility) if they will just let Jmol read their files!
Now to answer your question, from the links you gave me in the case of
unformatted mode, I can see that the first line with data (3rd) and from
Title Card Required potential=scf
Electrostatic potential from Total SCF Density
-5 -8.140940 -8.140940 -8.643459
5 atoms
negative indicates we have an extra line indicating the number of
orbitals in this file (separate surfaces)
voxel origin is (-8.140940, -8.140940, -8.643459)
the
7th on it is the atom info, (i don't see where the bond info would be
though)
6 6.000000 0.000000 0.000000 -2.130707
1 1.000000 0.000000 1.932284 -2.775380
1 1.000000 1.673407 -0.966142 -2.775380
1 1.000000 -1.673407 -0.966142 -2.775380
17 17.000000 0.000000 0.000000 1.241787
2 0 0
coordinates in BOHRS
no bond info in cube files
, lines from 4th to 6th are the voxel information for the surfaces.
50 0.333333 0.000000 0.000000
50 0.000000 0.333333 0.000000
55 0.000000 0.000000 0.333333
50x50x55 grid; each point laid out as a multiple of the specified
vector. In this case 1st are along X, second along Y, third along Z.
Now where I have the problem is in the volumetric data. Lines form 4 to 7
make the axes of the coordinate system used (centered in coordinates given
by the line 3 vector). Usually after that comes the volumetirc data with
one line for every N3 voxel,. Now there are N1*N2 lines meaning that you
have a vector of data for each discrete coordinate in the N1*N2 plane, and
thats ok.
The voxel data is just a steady stream of numbers that will be looped
through as (figuratively)
for(x from 1 to 50) {
for (y from 1 to 50) {
for (z from 1 to 55) {
readValueForPointXYZ()
}
}
}
Any line breaks are just for convenience, at least as far as Jmol is
concerned.
If I understand right an isosurface is formed by the conection of spacially
distributed coordinats (voxels for instance) with data in common, If one
does a search of any given number on a line of one of this cube files,
(take
for instance benzene-homo.cub which only has the Higher Order Molecular
Orbital info you wont find repeated data so easily) so wheres the catch for
isosurfaces.
Also regarding orbitals if I understand right in the line after the atoms
info you could have something like this
1 21
then form what its in Miguels java comments.
http://www.nersc.gov/nusers/resources/software/apps/chemistry/gaussian/g98/00000430.htm
its says:
For molecular orbital output, NAtoms will be less than zero, and an
additional record follows the data for the final atom (in format 10I5 if
the
file is formatted):
NMO, (MO(I),I=1,NMO) *Number of MOs and their numbers
*
If *N*MO orbitals were evaluated, then each record is *N*MO**N*3 long and
has the values for all orbitals at each point together.
then 1 21 will mean we have records of 1*N3 length but what will the 21
mean?
This means we have one orbital, the 21st one. (Probably in terms of
energy.)
Finally how the heck do you plot the isosurfaces if theres no data in
common
to link coordinates?
no data in common.... ?
The "marching cube" algorithm, as I sort of understand it, marches
down the grid of points, checking an 8-point, 12-edge cube as it goes.
.-----.-----o
/| /| /|
/ | / | / |
.-----.-----o | >>---->>
| .--+--.--+--o
| / | / | /
.-----.-----o
It identifies cubes that have only some vertices inside (.) and some
outside (o) the designated cutoff. The idea is that the surface must
go through this cube. (The one on the right, not the one on the left.)
It then selects all edges with one end inside and one end outside,
interpolates linearly between those values, and places a point (x) for
the surface at the appropriate position along the edge.
.--x--o
/| /|
/ | / |
.---x-o | >>---->>
| .x-+--o
| / | /
.---x-o
It then constructs the appropriate triangles for that set of edge
connections and goes on to the neighboring cube.
This is all done very efficiently using a set of tables that identify
what edges must be considered when any possible set of vertices are
inside/outside the surface.
What the JVXL format does is:
(a) identify all points in the stream of data where we cross the
surface, thus identifying all (.) and (o), and then
(b) identify the fractional distance from one end of each critical
edges to the other (where the "x" goes) and encodes that as an ASCII
character between 35 and 125.
These are the only two pieces of information required to draw a
monochromatic surface with 99% precision in relation to the position
of the surface within each voxel.
For colored surfaces, we also need a color index at each surface point
(x). This could be from the original data or it could be from mapping
a separate set of voxel or functional data onto it. I hope to add that
soon. It will be a set of ASCII characters again, because the
"rainbow" of colors is really just 36 distinct color values. It will
be the same length as the edge fractional distance string.
But first I need to understand how one maps information like this onto
a set of voxels or surface points.
Bob
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers