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 eric capps wrote: >hi there, > >i'm interested in doing some work with the animation capabilities of >jmol, but to be honest i'm not very sure where to start, having never >contributed to an open source project before. i've been talking with >bob hanson a bit and i suppose i'm most interested in contributing to >that particular build. > >it is my understanding that when handling animation, jmol attempts to >load the entire contents of the file into memory, and that for this >reason it is not capable of handling large animations (larger than the >capacity of memory anyway). is this correct? if so, it seems to me >that it would be possible to add a sort of stream or buffer capability >to the animation so that it only loads a certain selection of the >animation into memory, changing it as needed. would this be useful? > >any advice as to where to begin with this would be most appreciated. > > >_______________________________________________ >Jmol-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/jmol-developers > > _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
