bob, i've been revisiting this idea, and i have a few questions for you.
1) how quickly do you think jmol could handle a coordinate refresh? that is, a method, probably in the Frame class, which takes as input a set of coordinates and replaces the atoms in the "atoms" array with them. do you think it could potentially do this at a rate of several per second w/out being too computationally demanding? or is this not much better that simply reloading another model? i think this is in line with your original idea, and it's seeming more and more in line with mine. 2) if you do think this will work quickly enough, do you think i should work from the inside out, that is, from the Frame class to the ModelManager, and so on, out to Eval? or vice versa? what i think would be great is a command like: "update (# of atoms) (coordinates of atoms)" which changes atom coordinates (and potentially numbers of atoms) but retains all other information about the model. On 6/6/06, Bob Hanson <[EMAIL PROTECTED]> wrote: > Eric, > > Excellent! It seems to me the other group interested in this might be > Nico and the FAH project, where they have huge animations. So we might > want to get him involved as well. > > I think you have a great idea here, and it is a manageable piece of > code, because it potentially just effects a few components. The > prototype now has full multiple-file loading capabilities -- different > files into different frames, and this is what you can capitalize on, I > think. All we really need is some sort of simple scripting syntax that > allows you to replace the coordinates in a model without actually > rewriting the whole darned thing. So, let's see.... > > 1) We'll need a new way to tap into the file readers without trashing > what is currently loaded. This should be relatively easy, as the > JmolAdapter class does the file reading independently anyway, storing > all the coordinate information in a temporary holding structure that is > only later transferred to the model. > > 2) Realize that when multiple files are loaded or any time we have > multiple frames, the atoms are actually in one continuous stream. If you > have 10 models, and each has 15,000 atoms, then you have 150,000 stored > coordinates, frame.atoms[0] - frame.atoms[149999]. > > 3) The operation that is needed is to replace a specific subset block of > these atoms with new coordinates based on those in a file being read. > Fortunately, since we do not have the capability to destroy or add new > atoms, any atoms read from any file are saved as a continuous block. > Still, we don't really need to worry about that. Jmol has methods that > iterate through all the atoms in a specific frame (specific "model"). We > can just replace their coordinates using one very simple method. > > 4) I would recommend not thinking of this as opening a continuous stream > from some huge file, but rather opening specific single-model files and > replacing coordinates model-by-model. Is that compatible with your idea? > > 5) Take a look at > <http://www.stolaf.edu/people/hansonr/jmol/docs/viewer.gif>. This > graphic attempts to outline the major classes in the prototype and how > they are related. Most of this is irrelevant, but maybe it helps. (No > guarantee that it is 100% correct; I was definitely learning while doing > here.) The main thing to understand is that Viewer is the key class. > EVERYTHING goes through viewer. The important classes to this project > will be: > > Viewer > Frame > Atom > ModelManager > FileManager > RepaintManager (where all the automation is) > Eval (where the scripting is) > Token (where you create new commands) > > 6) The sequence of calls generally looks like this: > > Eval --> Viewer --> ModelManager --> Frame > > This is because scripts access generally useful, possibly public Viewer > methods, and Viewer can coordinate any other actions that might be > necessary with the other managers. ModelManager is where we check to see > that there really is a model (frame != null), and from there we > generally go straight to the frame, where the Atoms atom[] array holds > all the atom information. > > 7) I'd suggest we start by settling the design issues before you go > anywhere near the coding: > > A: What are the design parameters? What should this thing do? > > B: What should we call it? What options are needed? > > C: Should it run automatically, and if so, how do we stop and start it? > > 8) In terms of coding, what I usually do is first set up a new command > in Token and Eval, just enough so I can test. Then I create a series of > methods that get me from Eval to Frame as quickly and cleanly as > possible and do everything else there. Jmol is set up to allow you to > set up to four test flags from the script: > > set testFlag1 ON/OFF > set testFlag2 ON/OFF > set testFlag3 ON/OFF > set testFlag4 ON/OFF > > and you can use viewer.getTestFlag1(), viewer.getTestFlag2(), etc. from > just about anywhere in the code. > > 9) In terms of debugging, I'd like to hear what others have found works > form them. I use the applet almost exclusively, because I can save a > whole page of test scripts (those various .htm files referred to in > new.htm), and it only takes a few seconds to build and run. I know > others use the application straight from Eclipse, and I suspect I'm > doing it the hard way, considering the fact that I haven't a clue how to > set debugging test points and walk through the code line by line the way > I always do in Visual Basic. So I rely on lots of System.out.println() > calls. Anyway, for me this works, and I can't really imagine doing this > any FASTER than I do now. But let's here what others do. > > 10) We might run into some conflicts, so do keep me informed if you will > be modifying branches/bob200603. > > 11) As much as possible please don't commit broken code -- wait until > you have something you think works, then commit it. If there is any way > to dissect out the changes into subsets and commit them separately, > please do that. For instance, we have a new command, so commit just > Token and Eval changes. Or maybe Token, Eval, Viewer, ModelManager, and > just an empty Frame method to complete the loop. Then, in a separate > commit, add the guts of the new functionality. > > I think it's very doable, Eric. Let me know when you need any help. > > Bob > Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
