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=100&url=/
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
