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" + ("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
>
--
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
