eric capps wrote:
>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?
>
>
instantly. Each screen refresh retransforms the actual xyz coordinates.
So the very next refresh will update, and running through a list of
coordinates is about the fastest thing it can do. I would say 0 ms.
>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?
>
FAR better than reloading a model.
>i think this is in
>line with your original idea, and it's seeming more and more in line
>with mine.
>
>
>
right. There are a couple of schemes I can think of --
where you pick off coord in the coordList based on scanning the atomList
void replaceCoordinates(BitSet atomList, Point3f[] coordList) {
int ipt = 0;
for (int i = atomList.size(); --i >=0;)
if(atomList.get(i))
atoms[i].point3f.set(coordList[ipt++])
}
for example, would do the trick.
This would be in frame. Now, you need to "stitch" this into the code via
Viewer:
void replaceCoordinates(.....) {
modelManager.replaceCoordinates(...)
}
ModelManager:
void replaceCoordinates(.....) {
if(frame != null)
frame.replaceCoordinates(...)
}
and then call a Viewer function via the JmolViewer interface.
>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)"
>
>
Be more specific here. What do you actually mean? Perhaps:
update (atomno<=10) {coord1} {coord2} {coord3} ......
Are you sure we want this to be a script command? (this will slow the
operation considerably)
Question 1: Do you want to access this from a web page for the applet?
Question 2: Do you primarily want to use the application?
We could much better, I think, make this a JmolViewer interface function.
Bob
>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
>
>
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
