Re: [Jmol-developers] MD trajectories for 11.7
Hi Bob,
Thanks for the replies! Sorry I haven't gotten back to you yet; I was
out of town.
By the way, the talk of these mysterious simulations of mine appears
to be getting ever more murky, albeit in slight increments. If you're
curious, I'm processing data from simulations as described in Ab
Initio Multiple Spawning: Photochemistry from First Principles Quantum
Molecular Dynamics M. Ben-Nun, J. Quenneville, and T. J. Martinez, J.
Phys. Chem., 104, 5161 (2000). The implementation is usually MolPro
for the ab initio gradient calculations and AMBER for the classical
propagation, though my application is expected to deal with uniform
HDF5 output from any combination of QM and MM engines that a grad
student has managed to hitch together.
Feel free to take that or leave it, depending on your current state of
curiosity and free time.
Anyway...
On Thu, Oct 9, 2008 at 11:09 PM, Robert Hanson [EMAIL PROTECTED] wrote:
or if you wanted an animation, something like
var nSec = 0.1
for (var i = 1; i 10;i = i + 1)
script inline @{display 1. + i + , 2. + i}
delay @nSec
end for
This is basically what I'm doing, except I'm doing it in JavaScript.
I'd prefer to do it all in Jmol, but to do so, I'd need a way to store
some global array data. Because, in my app, each trajectory may start
at an essentially arbitrary time, I keep an array of which trajectory
frames are available at which times, and which frame number in the
trajectory file each is.
So...let's say there are 3 trajectories involved. Trajectory 1 starts
at time t=0, trajectory 2 starts at t=50, and trajectory 3 starts at
t=100. I then wish to provide an animation from t=0 onward, but not
display trajectories 2 and 3 until the appropriate animation frame.
My solution to this problem was to create an array like this:
time traj 1 frame traj 2 frame traj 3 frame
0 1 null null
10 2 null null
20 3 null null
30 4 null null
40 5 null null
50 6 1 null
60 7 2 null
70 8 2 null
80 9 4 null
90 10 5 null
10011 6 1
11012 7 2
This means that when it's time for animation frame 0, I execute
display 1.1, and when it's time for frame 5 (t=50), I execute
display 1.6, 2.1 and so on. The time data is important, too, as I
use it to echo the time for each animation frame. I store the
population (transparency) data in a different array of similar
construction. The only way I could figure out to store and access
that data was to store it all as a JavaScript array, and then use a
JavaScript loop to do the custom animation.
I see that Jmol has capacity to load and store per-atom data (the
DATA command), but might there be a way to store this more
globally-scoped table in Jmol somewhere? I confess, I don't have a
firm grasp of Jmol math yet.
I do use per-frame transparency, which would break if
color/transparency information is logically tied to the topology
rather than the coordinates (the latter being what changes on a
per-animation-frame basis). If there could be per-trajectory-frame
color attributes, it'd be a pretty big help. The only other helpful
thing would be more than 8 levels of transparency (though I can't
imagine more than 20 would matter).
All you do is make a for/end for loop as above and basically design your own
animation.
I'm unclear on what you mean here. Currently, I load everything
(every frame of every applicable trajectory), then loop over each
frame and set its transparency. This is all done right after the load
(takes forever in the current every-frame-is-a-model implementation),
and the animation is nothing but display ... and delay steps. Are
you saying to modify the loop to apply the transparency to each frame
right before it is displayed? Something like
for (var i = 1; i 10;i = i + 1)
script inline @{select 1. + i + , 2. + i}
color TRANSLUCENT 0.125
script inline @{display 1. + i + , 2. + i}
delay @nSec
end for
Eventually, my dream is to produce animations not only of the atoms
but also of molecular orbitals, but I strongly suspect that's too
computationally- or memory-intensive to do in an interactive
environment.
Nah. Actually, you could do this. It would require some initial set up.
I wonder how slow it would be:
1) set up your trajectory data.
2) create the molecular orbitals using Gaussian in terms of a CUBE file for
each stage along the way.
3) use Jmol or Jvxl.jar to create JVXL files (200:1 compressed surfaces) of
those orbitals from the CUBE files.
That's the slow part. Now load the
Re: [Jmol-developers] MD trajectories for 11.7
Matt, you are SO in luck. 1) You can define the array data, but it seems to me more appropriate just to define a starting point for each. Right? Something like this should do the job: # Jmol math here function runAnimation() frame * display none var timeStep = 10 #whatever var startTimes = array(0, 50,100) #whatever var endTimes = array(500,550,450) # whatever var secDelay = 0.5 #whatever var frameList = array(0,0,0) var endTime = 0 var time = 0 for (var i = 1; i = 3; i = i + 1) if (time = startTimes[i]) time = startTimes[i] endif if (endTime = endTimes[i]) endTime = endTimes[i] endif end for while(time endTime) var s = for (var i = 1; i = 3; i = i + 1) if (time = startTimes[i] time = endTimes[i]) frameList[i] = frameList[i] + 1 if (s != ) s = s + , end if s = s + i + . + frameList[i] end if end for s = frame + s + ;delay + secDelay script inline @s time = time + timeStep end while end function The only way I could figure out to store and access that data was to store it all as a JavaScript array, and then use a JavaScript loop to do the custom animation. I see that Jmol has capacity to load and store per-atom data (the DATA command), but might there be a way to store this more globally-scoped table in Jmol somewhere? I confess, I don't have a firm grasp of Jmol math yet. any data -- not just per atom. I'm unclear on what you mean here. Currently, I load everything (every frame of every applicable trajectory), then loop over each frame and set its transparency. This is all done right after the load (takes forever in the current every-frame-is-a-model implementation), and the animation is nothing but display ... and delay steps. Are you saying to modify the loop to apply the transparency to each frame right before it is displayed? Something like well, in this case what you would do is define the translucency for each model just before you display it. That's a really interesting idea. I don't have CUBE files available, nor will I ever for this particular application (I have expansion coefficients only), so I'd have to have the additional step of calculating the MO value as a function of X,Y,Z for each frame. Using Jmol you could pre-save the MOs as JVXL files and very quickly load them in on the fly. -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
Re: [Jmol-developers] MD trajectories for 11.7
Matt, I did check this out more carefully, and I see now that there was a
bug in Jmol for appended trajectories. It's fixed, but it's in Jmol 11.7.3,
which has not been released yet. If you are interested in getting a look at
this, take a look at
http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm?topic=1
JAR files for 11.7.3 are in
http://chemapps.stolaf.edu/jmol/docs/examples-11/Jmol-11.zip
Bob
On Thu, Oct 9, 2008 at 10:09 PM, Robert Hanson [EMAIL PROTECTED] wrote:
Hey, Matt, you might be in luck.
On Thu, Oct 9, 2008 at 2:01 PM, Matthew Zwier [EMAIL PROTECTED] wrote:
At least, I think you can Supposed to be able to. You are just
limited
to one trajectory step from EACH sequence loaded. I can't imagine why
that
would take any major amount of time if they are trajectories.
Yeah, as I said above, they're loaded as independent models, not
trajectories. It gets slow when the total number of atoms gets large,
as I suppose one would expect if there's a loop over all 40,000 atoms
occurring each animation frame.
I'm happy to do the coding if anything is necessary there. Doesn't sound
too
involved to me. Keep talking
Sounds like the machinery is there already, and that I just haven't
kept up with recent development enough to know. Loading each run as a
trajectory should do it.
Right. It's all there. You can't use both the append and the trajectory
keywords at the same time right now, but in this case you don't need the
trajectory keyword, so you can do:
load files u.mdtop FILTER ![WAT],![URE] COORD {0 -1 5}
mdcrd::prod1.mdcrd mdcrd::prod2.mdcrd
load append u.mdtop FILTER ![WAT],![URE] COORD {0 -1 5}
mdcrd::prod3.mdcrd mdcrd::prod4.mdcrd
frame *;
display 1.1,2.1
delay 0.1
display 1.2,2.2
delay 0.1
display 1.3,2.3
delay 0.1
...
or if you wanted an animation, something like
var nSec = 0.1
for (var i = 1; i 10;i = i + 1)
script inline @{display 1. + i + , 2. + i}
delay @nSec
end for
I tried this on a simple model (7700 atoms), and it went very smoothly.
Note that if you add a write command (and you are using the Jmol
application), then you can make a movie of the overlaid trajectories:
for (var i = 1; i 10;i = i + 1)
script inline @{display 1. + i + , 2. + i}
write image 500 500 @{movie + ( + i)[-3][0] + .jpg}
end for
And then use some other software to combine those JPEG stills into an AVI
file.
I do use per-frame transparency, which would break if
color/transparency information is logically tied to the topology
rather than the coordinates (the latter being what changes on a
per-animation-frame basis). If there could be per-trajectory-frame
color attributes, it'd be a pretty big help. The only other helpful
thing would be more than 8 levels of transparency (though I can't
imagine more than 20 would matter).
All you do is make a for/end for loop as above and basically design your
own animation.
Eventually, my dream is to produce animations not only of the atoms
but also of molecular orbitals, but I strongly suspect that's too
computationally- or memory-intensive to do in an interactive
environment.
Nah. Actually, you could do this. It would require some initial set up.
I wonder how slow it would be:
1) set up your trajectory data.
2) create the molecular orbitals using Gaussian in terms of a CUBE file for
each stage along the way.
3) use Jmol or Jvxl.jar to create JVXL files (200:1 compressed surfaces) of
those orbitals from the CUBE files.
That's the slow part. Now load the trajectory data, and as above drive the
animation, but this time include an isosurface command that loads the
desired surface from the JVXL files.
If these are reasonably small molecules, I'll bet the JVXL file will load
and display almost instantly.
Might work.
Bob
Thanks for the reply and discussion!
Cheers,
Matt Z.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is
Re: [Jmol-developers] MD trajectories for 11.7
Matt, good to hear this! Comments below. - Bob
On Wed, Oct 8, 2008 at 10:09 PM, Matthew Zwier [EMAIL PROTECTED] wrote:
Hi all,
A few days ago, Bob Hanson mentioned that improved support for display
of MD trajectories is on the docket for 11.7. I'm interested in
surveying the lay of the land and possibly helping out with the coding
for MD trajectory support. I have a couple questions/thoughts, mostly
related to what's feasible given the underlying data structures.
1) Are there plans to support simultaneous display of multiple
trajectories?
The big issue is memory. Jmol can handle about 120,000 atoms (at least on my
machine) before it chokes. Let's make sure we are using the same language.
Trajectory is a full sequence, Trajectory Step is a single snapshot.
Yes?
So one has to involve some sort of reasonable selectivity here.
The way the file reader works is that any number of models can be loaded
simultaneously. In the case of standard multi-model PDB files, these models
can be read either as totally independent models or as trajectories where
only one step can be displayed at a time, because there are only that many
atoms really created. Changing frames simply changes the coordinates.
(Like the old CHIIME multiple-xyz file business.)
1a) If so, I'd be interested in coordinating the animation of
multiple trajectories according to some global notion of time. This
would allow for displaying ensembles of trajectories, each of which
may start and/or end at a different time. I've hacked something like
this together with multi-frame XYZ files and JavaScript, but it's
prohibitively slow (each call to display 1.10,2.5,3.1... takes
tenths of seconds on a Core 2 Duo); something internal to the applet
would be much more efficient.
You mean each of these 1, 2, 3 files are each a full trajectory, and you
want to simultaneously overlay x number of trajectory steps? Is that useful?
2) Are Jmol's data structures amenable to something like the above,
or would it require enough of a re-write that it would cause more
trouble than it would solve? I've worked with Jmol before (on the
development side), but I don't have enough experience to answer that
one.
All depends upon what you really want. Right now you can certainly load
multiple topology files so that, say, 1.1-1.100 are trajectory steps for run
1, and 2.1-2.100 are trajectory steps for run 2. And then you can certainly
display {1.1 or 2.1 or ...}
At least, I think you can Supposed to be able to. You are just limited
to one trajectory step from EACH sequence loaded. I can't imagine why that
would take any major amount of time if they are trajectories.
This kind of thing is clearly an edge-case compared to the single
large trajectory that's so common, but it's something no other
visualization tool I know of can do (let alone one that can be
embedded in a web page to monitor a running simulation.) As I said
above, I'm willing to help out on it if you all think it would be a
useful thing to have.
I'm happy to do the coding if anything is necessary there. Doesn't sound too
involved to me. Keep talking
Cheers,
Matt Zwier
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Re: [Jmol-developers] MD trajectories for 11.7
Hi Bob,
On Thu, Oct 9, 2008 at 10:10 AM, Robert Hanson [EMAIL PROTECTED] wrote:
Matt, good to hear this! Comments below. - Bob
1) Are there plans to support simultaneous display of multiple
trajectories?
The big issue is memory. Jmol can handle about 120,000 atoms (at least on my
machine) before it chokes. Let's make sure we are using the same language.
Trajectory is a full sequence, Trajectory Step is a single snapshot.
Yes?
Yes.
So one has to involve some sort of reasonable selectivity here.
The way the file reader works is that any number of models can be loaded
simultaneously. In the case of standard multi-model PDB files, these models
can be read either as totally independent models or as trajectories where
only one step can be displayed at a time, because there are only that many
atoms really created. Changing frames simply changes the coordinates.
(Like the old CHIIME multiple-xyz file business.)
Sounds good. As of a couple months ago, the online scripting docs
indicated that only one model could be loaded as a trajectory. So
I've been reading as multiple independent models.
1a) If so, I'd be interested in coordinating the animation of
multiple trajectories according to some global notion of time. This
would allow for displaying ensembles of trajectories, each of which
may start and/or end at a different time. I've hacked something like
this together with multi-frame XYZ files and JavaScript, but it's
prohibitively slow (each call to display 1.10,2.5,3.1... takes
tenths of seconds on a Core 2 Duo); something internal to the applet
would be much more efficient.
You mean each of these 1, 2, 3 files are each a full trajectory, and you
want to simultaneously overlay x number of trajectory steps? Is that useful?
Correct on all points. Each of the x steps occur at the same time in
multiple simultaneous trajectories. It isn't at all useful for people
doing long-time dynamics, but it is useful for simulations involving
an ensemble of trajectories.
In my case, a small ensemble of simultaneously-evolving dynamics
trajectories is used to approximate and propagate the total (nuclear
and electronic) wavefunction of a system whose dynamics are determined
by multiple electronic states (photodissociation reactions, for
instance). I color each trajectory differently, set the transparency
for the atoms in each trajectory frame according to that frame's
weight in the total wavefunction at that time, and animate. Watching
the evolution of multiple trajectories simultaneously gives an
intuitive feel for how much of the dynamics is governed by each
electronic state.
2) Are Jmol's data structures amenable to something like the above,
or would it require enough of a re-write that it would cause more
trouble than it would solve? I've worked with Jmol before (on the
development side), but I don't have enough experience to answer that
one.
All depends upon what you really want. Right now you can certainly load
multiple topology files so that, say, 1.1-1.100 are trajectory steps for run
1, and 2.1-2.100 are trajectory steps for run 2. And then you can certainly
display {1.1 or 2.1 or ...}
At least, I think you can Supposed to be able to. You are just limited
to one trajectory step from EACH sequence loaded. I can't imagine why that
would take any major amount of time if they are trajectories.
Yeah, as I said above, they're loaded as independent models, not
trajectories. It gets slow when the total number of atoms gets large,
as I suppose one would expect if there's a loop over all 40,000 atoms
occurring each animation frame.
I'm happy to do the coding if anything is necessary there. Doesn't sound too
involved to me. Keep talking
Sounds like the machinery is there already, and that I just haven't
kept up with recent development enough to know. Loading each run as a
trajectory should do it.
I do use per-frame transparency, which would break if
color/transparency information is logically tied to the topology
rather than the coordinates (the latter being what changes on a
per-animation-frame basis). If there could be per-trajectory-frame
color attributes, it'd be a pretty big help. The only other helpful
thing would be more than 8 levels of transparency (though I can't
imagine more than 20 would matter).
Eventually, my dream is to produce animations not only of the atoms
but also of molecular orbitals, but I strongly suspect that's too
computationally- or memory-intensive to do in an interactive
environment.
Thanks for the reply and discussion!
Cheers,
Matt Z.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [Jmol-developers] MD trajectories for 11.7
Hey, Matt, you might be in luck.
On Thu, Oct 9, 2008 at 2:01 PM, Matthew Zwier [EMAIL PROTECTED] wrote:
At least, I think you can Supposed to be able to. You are just
limited
to one trajectory step from EACH sequence loaded. I can't imagine why
that
would take any major amount of time if they are trajectories.
Yeah, as I said above, they're loaded as independent models, not
trajectories. It gets slow when the total number of atoms gets large,
as I suppose one would expect if there's a loop over all 40,000 atoms
occurring each animation frame.
I'm happy to do the coding if anything is necessary there. Doesn't sound
too
involved to me. Keep talking
Sounds like the machinery is there already, and that I just haven't
kept up with recent development enough to know. Loading each run as a
trajectory should do it.
Right. It's all there. You can't use both the append and the trajectory
keywords at the same time right now, but in this case you don't need the
trajectory keyword, so you can do:
load files u.mdtop FILTER ![WAT],![URE] COORD {0 -1 5}
mdcrd::prod1.mdcrd mdcrd::prod2.mdcrd
load append u.mdtop FILTER ![WAT],![URE] COORD {0 -1 5}
mdcrd::prod3.mdcrd mdcrd::prod4.mdcrd
frame *;
display 1.1,2.1
delay 0.1
display 1.2,2.2
delay 0.1
display 1.3,2.3
delay 0.1
...
or if you wanted an animation, something like
var nSec = 0.1
for (var i = 1; i 10;i = i + 1)
script inline @{display 1. + i + , 2. + i}
delay @nSec
end for
I tried this on a simple model (7700 atoms), and it went very smoothly.
Note that if you add a write command (and you are using the Jmol
application), then you can make a movie of the overlaid trajectories:
for (var i = 1; i 10;i = i + 1)
script inline @{display 1. + i + , 2. + i}
write image 500 500 @{movie + ( + i)[-3][0] + .jpg}
end for
And then use some other software to combine those JPEG stills into an AVI
file.
I do use per-frame transparency, which would break if
color/transparency information is logically tied to the topology
rather than the coordinates (the latter being what changes on a
per-animation-frame basis). If there could be per-trajectory-frame
color attributes, it'd be a pretty big help. The only other helpful
thing would be more than 8 levels of transparency (though I can't
imagine more than 20 would matter).
All you do is make a for/end for loop as above and basically design your own
animation.
Eventually, my dream is to produce animations not only of the atoms
but also of molecular orbitals, but I strongly suspect that's too
computationally- or memory-intensive to do in an interactive
environment.
Nah. Actually, you could do this. It would require some initial set up.
I wonder how slow it would be:
1) set up your trajectory data.
2) create the molecular orbitals using Gaussian in terms of a CUBE file for
each stage along the way.
3) use Jmol or Jvxl.jar to create JVXL files (200:1 compressed surfaces) of
those orbitals from the CUBE files.
That's the slow part. Now load the trajectory data, and as above drive the
animation, but this time include an isosurface command that loads the
desired surface from the JVXL files.
If these are reasonably small molecules, I'll bet the JVXL file will load
and display almost instantly.
Might work.
Bob
Thanks for the reply and discussion!
Cheers,
Matt Z.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
[Jmol-developers] MD trajectories for 11.7
Hi all, A few days ago, Bob Hanson mentioned that improved support for display of MD trajectories is on the docket for 11.7. I'm interested in surveying the lay of the land and possibly helping out with the coding for MD trajectory support. I have a couple questions/thoughts, mostly related to what's feasible given the underlying data structures. 1) Are there plans to support simultaneous display of multiple trajectories? 1a) If so, I'd be interested in coordinating the animation of multiple trajectories according to some global notion of time. This would allow for displaying ensembles of trajectories, each of which may start and/or end at a different time. I've hacked something like this together with multi-frame XYZ files and JavaScript, but it's prohibitively slow (each call to display 1.10,2.5,3.1... takes tenths of seconds on a Core 2 Duo); something internal to the applet would be much more efficient. 2) Are Jmol's data structures amenable to something like the above, or would it require enough of a re-write that it would cause more trouble than it would solve? I've worked with Jmol before (on the development side), but I don't have enough experience to answer that one. This kind of thing is clearly an edge-case compared to the single large trajectory that's so common, but it's something no other visualization tool I know of can do (let alone one that can be embedded in a web page to monitor a running simulation.) As I said above, I'm willing to help out on it if you all think it would be a useful thing to have. Cheers, Matt Zwier - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
