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" + ("0000" + 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=100&url=/
> _______________________________________________
> 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=100&url=/
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to