Re: [Jmol-users] large animations

Bob Hanson Fri, 26 May 2006 14:16:11 -0700

Wonderful. It's the "bob200603" branch.
I rarely mess it up too much these days....


Do you subscribe to the developer list?
If so, I'm moving this to that list.
Bob



eric capps wrote:

bob,

thanks for your continuing help. every time you answer a question it
seems to answer about 10 i hadn't thought to ask yet.

is your source for 10.x available? i'd love to see if i can't help addanything.


eric

On 5/26/06, Bob Hanson <[EMAIL PROTECTED]> wrote:

[note: this message relates to the experimental prototype "Jmol 10.x" not
the public release Jmol 10.2. See

http://www.stolaf.edu/people/hansonr/jmol/test/proto/new.htm fordetails.]


eric capps wrote:

> bob,
>
> so if you have 1 model whose atoms you continually change with 1000
> atoms you have i = 0 - 999? i may very well end up using this method
> instead! let me know if there's any debugging/coding i can help with.
> do you still consider these methods "highly experimental"?

oh, yeah. We are tapping into core classes directly via JavaScipt.Absolutely no

guarantees. Be the first on your block....

>
> i'm still trying to make the following work properly:
>
> function loadNext(file){
>     jmolSaveOrientation("save1");
>     jmolScriptWait("load "+file);
>     jmolRestoreOrientationDelayed("save1",0);
>     makeNext();

var oldOrientation = jmolSaveOrientation("save1").replace(/1/,"0");
//changes this to "moveTo 0.0 ...." instead of "moveTo 1.0...."
jmolScriptWait("load "+file + ";" + oldOrientation);



> }
>
> you can ignore makeNext(), it just figures out which model to load
> next. unfortunately there's still about a 1/10th of a second delay
> between when the next file is loaded and when the orientation is
> restored. and also, this approach unfortunately does not save any
> information from label or render or anything else.

THAT's true.

i wonder, is it
> possible to specify all of these parameters in a "load" statement?
> failing that, is there a way to synchronize these commands tighter?
> i'd be happy to work on this, but i'm still trying to figure out
> exactly how jmol and jmol-new.js work together.

keep playing... and asking....

>
> eric
>
> On 5/25/06, Bob Hanson <[EMAIL PROTECTED]> wrote:
>
>> Eric,
>>
>> yeah, that's it. Starting with 0 and NOT repeating for each model --
>> 10 models of benzene would have i=0,1,2,....,i=119. Even if the data
>> are coming from different files, that number still just starts at 0
>> and runs.
>>
>> We don't recommend people fiddling with that, but in this case, it's
>> an experiment. That's the only reliable tag you have.
>>
>> It's also the number that's displayed if you use
>>
>> select *;label %D
>>
>> It's called the atom "index" number.
>>
>> Bob
>>
>>
>> eric capps wrote:
>>

>> > wow, yeah. so does move, save, move, restore (w/out the secondsave).

>> >
>> > regarding the jmolSetAtomCoord function, what does 'i' refer to? i'm
>> > guessing it's the atom number in the order that jmol read them?
>> >
>> > On 5/25/06, Bob Hanson <[EMAIL PROTECTED]> wrote:
>> >
>> >> Eric,
>> >>

>> >> I think there's something wrong with the data for the "home"position.

>> >> If you  first move the model around and THEN save, move some more,
>> >> save, they all work, right?
>> >>
>> >> Bob
>> >>
>> >>
>> >> eric capps wrote:
>> >> > bob,
>> >> >
>> >> > may be my environment but this isn't quite working for me. the
>> restore
>> >> > delayed function doesn't seem to do anything at all! does this
>> work on
>> >> > your end?
>> >> >
>> >> > eric
>> >> >
>> >> > On 5/25/06, Bob Hanson <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> >> what delay? Oh, THAT delay. Sure. see
>> >> >>
>> >> >> http://www.stolaf.edu/people/hansonr/jmol/test/proto/Jmol-new.js
>> >> >> http://www.stolaf.edu/people/hansonr/jmol/test/proto/new.htm
>> >> >>
>> >> >> jmolRestoreOrientationDelayed(id,delay,targetSuffix)
>> >> >>
>> >> >> -- id should correspond to same for jmolSaveOrientation()
>> >> >> -- delay defaults to 1 second
>> >> >> -- can be set to anything
>> >> >> -- targetSuffix optional
>> >> >>
>> >> >> Bob
>> >> >>
>> >> >> eric capps wrote:
>> >> >>
>> >> >> > bob,
>> >> >> >
>> >> >> > can you think of a way to do a restore orientation w/out the
>> delay?
>> >> >> > since i'm trying to use it in place of the built in animation
>> >> >> > capability, i want it to be able to snap back in position
>> >> immediately.
>> >> >> >
>> >> >> > On 5/23/06, Bob Hanson <[EMAIL PROTECTED]> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> Eric Capps wrote:
>> >> >> >>
>> >> >> >> > bob,
>> >> >> >> >
>> >> >> >> > i believe i have the most recent version of jmol, but my
>> jmol.js

>> >> >> >> > doesn't have these functions anywhere in it. thejmol-new.js

>> >> on the
>> >> >> >> > page you linked me to seems to be older, but it does have
>> these

>> >> >> >> > functions. what's the deal with that? does my versionnot have

>> >> that
>> >> >> >> > functionality?
>> >> >> >>

>> >> >> >> oops, sorry, it isn't older -- it's just that I've ignoredthe

>> >> header.
>> >> >> >> the two key files are JmolAppletProto.jar and Jmol-new.js in
>> >> >> >>
>> >> >> >> http://www.stolaf.edu/people/hansonr/jmol/test/proto
>> >> >> >>

>> >> >> >> if you use this, comment out your jmolInitialize() calland have

>> >> >> >> JmolAppletProto.jar in the same directory as your HTML page.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > what you are describing sounds very interesting but is
>> >> >> unfortunately a
>> >> >> >> > bit over my head, as i'm new to both jmol and javascript.
>> >> still, i'd
>> >> >> >> > like to give it a shot.
>> >> >> >> >
>> >> >> >> > so am i right in thinking that you are suggesting writing a
>> >> method

>> >> >> >> > which would perform animation by moving an atom or agroup of

>> >> atoms
>> >> >> >> > rather than reading an entire list of coordinates? this
>> would be
>> >> >> >> > particularly helpful as the animations i am trying to make
>> >> typically

>> >> >> >> > only have one or two atoms moving at once (out ofthousands).

>> >> would

>> >> >> >> > this be written in the jmol source code or the jmol.jsfile?

>> >> >> >>

>> >> >> >> Ah, there you go. Then you are all set! Can you figure outwhich

>> >> atoms
>> >> >> >> are
>> >> >> >> changing? That's interesting. OK, just for you, Eric:
>> >> >> >>
>> >> >> >> http://www.stolaf.edu/people/hansonr/jmol/test/proto/new.htm
>> >> >> >>
>> >> >> >> Fun, eh? This should give you some ideas.
>> >> >> >>
>> >> >> >> It will probably not work on Macs. What are your parameters
>> in that
>> >> >> >> regard?
>> >> >> >>

>> >> >> >> If you want to change a WHOLE LOT of atom positions,though, we

>> >> should
>> >> >> >> pass the
>> >> >> >> applet a string and let it parse the string for atoms.
>> >> >> >>
>> >> >> >>
>> >> >> >> Bob
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > -eric
>> >> >> >> >
>> >> >> >> > On 5/23/06, Bob Hanson <[EMAIL PROTECTED]> wrote:
>> >> >> >> >
>> >> >> >> >> what a challenge!
>> >> >> >> >>

>> >> >> >> >> Keeping the orientation after a file load is noproblem. Jmol

>> >> 10.x
>> >> >> >> >> allows the
>> >> >> >> >> following:
>> >> >> >> >>
>> >> >> >> >> jmolSaveOrientation()
>> >> >> >> >> jmolScriptWait("load....")
>> >> >> >> >> jmolRestoreOrientation()
>> >> >> >> >>

>> >> >> >> >> So then the orientation resets to the original. You cansee

>> >> this in
>> >> >> >> >> action at
>> >> >> >> >> http://fusion.stolaf.edu/chemistry/jmol/xtalx . There are
>> links
>> >> >> in the
>> >> >> >> >> lower
>> >> >> >> >> left panel under "orientation" for "save" and "restore".
>> >> These work
>> >> >> >> >> across file
>> >> >> >> >> loads.
>> >> >> >> >>
>> >> >> >> >> 10.x also allows proper loading of multiple files. The
>> problem
>> >> >> you are
>> >> >> >> >> going to
>> >> >> >> >> run into is that every atom has to be saved individually,
>> so you
>> >> >> are
>> >> >> >> >> looking at
>> >> >> >> >> 100000 x (nAtoms) of atoms in memory. Not feasible.
>> >> >> >> >>
>> >> >> >> >> The better solution, it seems to me, would be to have a
>> limited
>> >> >> number
>> >> >> >> >> of active
>> >> >> >> >> frames (say, 10) and then actively CHANGE the atom
>> positions as
>> >> >> >> >> needed. Think of

>> >> >> >> >> the set of atoms as a "buffer" that we are going tofill as

>> >> needed.
>> >> >> >> >> When the

>> >> >> >> >> user is watching frame 3, we are loading frame 2; theygo to

>> >> >> frame 4,
>> >> >> >> >> we load

>> >> >> >> >> frame 3. Sort of the way a word processor processes alarge

>> >> >> document.
>> >> >> >> >> It doesn't

>> >> >> >> >> have to load the whole thing -- just what you arelooking at.

>> >> One
>> >> >> >> >> would just
>> >> >> >> >> fill them as needed and display them in some sequence.
>> >> >> >> >>

>> >> >> >> >> So, it seems to me, the solution is to have thecapability of

>> >> >> loading
>> >> >> >> >> atom

>> >> >> >> >> positions independently of the atoms themselves -- sortof a

>> >> >> >> "replace" or

>> >> >> >> >> "loadCoordinates" capability rather than a "load"capability,

>> >> >> and at
>> >> >> >> >> the frame
>> >> >> >> >> level rather than the "model set" level. Or, for that
>> matter, at
>> >> >> the
>> >> >> >> >> atom level,
>> >> >> >> >> not the model level.
>> >> >> >> >>

>> >> >> >> >> It would only work for situations where the bonding andatoms

>> >> were
>> >> >> >> >> identical in
>> >> >> >> >> each "frame", but I think this is what you are thinking.
>> Since
>> >> >> all you
>> >> >> >> >> need are

>> >> >> >> >> the xyz coordinates, the syntax is trivial -- I couldimagine

>> >> >> >> >> accepting xyz
>> >> >> >> >> files, since they are so simple, but one could also
>> imagine just
>> >> >> >> >> straight x y z
>> >> >> >> >> x y z x y z down the line. A very simple reader.
>> >> >> >> >>
>> >> >> >> >> Maybe the syntax would be something like:
>> >> >> >> >>
>> >> >> >> >> loadCoordinates FILENAME [optional model number]
>> >> >> >> >>
>> >> >> >> >> Personally, I would drive the whole thing with JavaScript
>> >> based on
>> >> >> >> >> that sequence
>> >> >> >> >> file, and as the frames change and send back their
>> frame-change
>> >> >> >> callback
>> >> >> >> >> message, execute the loads. In fact, if you set up the
>> animation
>> >> >> as a
>> >> >> >> >> loop 1 2 3

>> >> >> >> >> 4 5 1 2 3 4 5 1 2 3 4 5, then you get a message backthat you

>> >> >> are on
>> >> >> >> >> frame X any
>> >> >> >> >> time. The JavaScript would then call to load frame X+3
>> with file
>> >> >> Y+3,
>> >> >> >> >> and the

>> >> >> >> >> animation could just run and run, and the user couldtwiddle

>> >> >> with the
>> >> >> >> >> mouse all

>> >> >> >> >> he/she wants, and it would just be a gas. They couldstart,

>> >> stop,
>> >> >> >> >> rewind, etc.
>> >> >> >> >> You would just have to carefully sync the frame loading
>> with the
>> >> >> >> >> user's trajectory.
>> >> >> >> >>
>> >> >> >> >> Certainly doable. Sound interesting?
>> >> >> >> >>
>> >> >> >> >> Bob Hanson
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Eric Capps wrote:
>> >> >> >> >> > i'm trying to create a very large animation. it maps the
>> >> >> movement of
>> >> >> >> >> > around 1000 atoms, over potentially hundreds of
>> thousands of
>> >> >> steps,

>> >> >> >> >> > with as many as 10000 unique states (there aresituations

>> >> where a

>> >> >> >> >> > series of steps repeat themselves many times). i amnew to

>> >> >> jmol, and
>> >> >> >> >> > from the demonstrations it seems that animation only
>> works on
>> >> >> >> >> > multi-frame files. for hundreds of thousands of steps,
>> this is
>> >> >> >> >> > unfeasible.
>> >> >> >> >> >

>> >> >> >> >> > i have each unique state stored in its own .xyz file,and

>> >> another
>> >> >> >> file
>> >> >> >> >> > which lists the order in which they occur. i thought to
>> make a
>> >> >> >> >> > multi-frame .xyz of only the unique states and specify
>> them by
>> >> >> frame
>> >> >> >> >> > number when they repeat, but this still creates a very
>> >> large file
>> >> >> >> >> > (around 100 megs), far larger than i feel it has to be.
>> >> >> >> >> >
>> >> >> >> >> > now, i am trying to create a script which uses load
>> >> statements as

>> >> >> >> >> > necessary to load the next, potentially repeated .xyzfile,

>> >> but i
>> >> >> >> want
>> >> >> >> >> > the user to be able to make changes to the view and have
>> them
>> >> >> not be

>> >> >> >> >> > reset every time a new .xyz is loaded. is thispossible? if

>> >> not,
>> >> >> >> does
>> >> >> >> >> > anyone have any ideas on how to implement very large
>> >> animations?
>> >> >> >> >> >
>> >> >> >> >> > thanks,
>> >> >> >> >> > eric
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > -------------------------------------------------------
>> >> >> >> >> > 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
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>