From: eric c. <dif...@gm...> - 2006-05-25 19:53:12
|
something else you've probably caught already: in all of the save/restore orientation methods you misspelled suffix as sufix. so if you're having trouble with those that's probably why. On 5/25/06, Bob Hanson <ha...@st...> 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 <ha...@st...> 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. the jmol-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 version not have that > >> > functionality? > >> > >> oops, sorry, it isn't older -- it's just that I've ignored the 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() call and 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 a group 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 of thousands). would > >> > this be written in the jmol source code or the jmol.js file? > >> > >> Ah, there you go. Then you are all set! Can you figure out which 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 <ha...@st...> wrote: > >> > > >> >> what a challenge! > >> >> > >> >> Keeping the orientation after a file load is no problem. Jmol 10.x > >> >> allows the > >> >> following: > >> >> > >> >> jmolSaveOrientation() > >> >> jmolScriptWait("load....") > >> >> jmolRestoreOrientation() > >> >> > >> >> So then the orientation resets to the original. You can see 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 to fill as needed. > >> >> When the > >> >> user is watching frame 3, we are loading frame 2; they go to frame 4, > >> >> we load > >> >> frame 3. Sort of the way a word processor processes a large document. > >> >> It doesn't > >> >> have to load the whole thing -- just what you are looking at. One > >> >> would just > >> >> fill them as needed and display them in some sequence. > >> >> > >> >> So, it seems to me, the solution is to have the capability of loading > >> >> atom > >> >> positions independently of the atoms themselves -- sort of 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 and atoms 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 could imagine > >> >> 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 back that 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 could twiddle with the > >> >> mouse all > >> >> he/she wants, and it would just be a gas. They could start, 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 are situations where a > >> >> > series of steps repeat themselves many times). i am new 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 .xyz file, 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 this possible? 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 > >> >> > > >> >> > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > >> >> > _______________________________________________ > >> >> > Jmol-users mailing list > >> >> > Jmo...@li... > >> >> > https://lists.sourceforge.net/lists/listinfo/jmol-users > >> >> > >> >> -- > >> >> -- > >> >> > >> >> Robert M. Hanson, ha...@st..., 507-646-3107 > >> >> Professor of Chemistry, St. Olaf College > >> >> 1520 St. Olaf Ave., Northfield, MN 55057 > >> >> mailto:ha...@st... > >> >> http://www.stolaf.edu/people/hansonr > >> >> > >> >> "Imagination is more important than knowledge." - Albert Einstein > >> >> > >> >> > >> >> > >> >> ------------------------------------------------------- > >> >> 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 > >> >> > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > >> >> _______________________________________________ > >> >> Jmol-users mailing list > >> >> Jmo...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/jmol-users > >> >> > >> > > >> > > >> > ------------------------------------------------------- > >> > 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 > >> > > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > >> > _______________________________________________ > >> > Jmol-users mailing list > >> > Jmo...@li... > >> > https://lists.sourceforge.net/lists/listinfo/jmol-users > >> > >> -- > >> -- > >> > >> Robert M. Hanson, ha...@st..., 507-646-3107 > >> Professor of Chemistry, St. Olaf College > >> 1520 St. Olaf Ave., Northfield, MN 55057 > >> mailto:ha...@st... > >> http://www.stolaf.edu/people/hansonr > >> > >> "Imagination is more important than knowledge." - Albert Einstein > >> > >> > >> > >> ------------------------------------------------------- > >> 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 > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > >> _______________________________________________ > >> Jmol-users mailing list > >> Jmo...@li... > >> https://lists.sourceforge.net/lists/listinfo/jmol-users > >> > > > > > > ------------------------------------------------------- > > 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 > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > > _______________________________________________ > > Jmol-users mailing list > > Jmo...@li... > > https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- > -- > > Robert M. Hanson, ha...@st..., 507-646-3107 > Professor of Chemistry, St. Olaf College > 1520 St. Olaf Ave., Northfield, MN 55057 > mailto:ha...@st... > http://www.stolaf.edu/people/hansonr > > "Imagination is more important than knowledge." - Albert Einstein > > > > ------------------------------------------------------- > 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 > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > |