From: eric c. <dif...@gm...> - 2006-06-06 01:51:31
|
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. |
From: Bob H. <ha...@st...> - 2006-06-06 14:38:58
|
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 >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-developers > > |
From: Nicolas V. <nve...@cl...> - 2006-06-06 18:50:46
|
Bob Hanson 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. > Yes, I could be interested, but currently I have no time available to work on Jmol in the next weeks. > 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.... > What about files with different number of atoms, files with several number of models, ... > 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. > Under Eclipse : - open the source file you want to debug - double click on the left border of the file (the grey area) -> you have added a breakpoint (a little blue circle should appear) - start the application using the "Debug" drop down menu instead of the "Run" menu The rest is really easy after Nico |
From: eric c. <dif...@gm...> - 2006-06-22 22:02:56
|
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 <ha...@st...> 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 > |
From: Bob H. <ha...@st...> - 2006-06-23 12:47:50
|
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 <ha...@st...> 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 >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-developers > > |
From: eric c. <dif...@gm...> - 2006-06-23 17:50:33
|
On Jun 23, 2006, at 7:52 AM, Bob Hanson wrote: > 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. bob, what is the purpose of the atomList variable here? in particular, why are you using a BitSet? is it supposed to indicate which coordinates are to be replaced? >> 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. you're right, a script command isn't the best way. for my purposes this would be in an applet context. new coordinates (i.e. calls to this method) would be passed in either through javascript (and i guess Jmol-new.js) or a separate java control applet. that's another issue that is probably outside the scope of this topic, is it easy to allow another embedded applet in the same page communicate with jmol? |
From: Bob H. <ha...@st...> - 2006-06-23 19:21:44
|
I notice I should have written void replaceCoordinates(BitSet atomList, Point3f[] coordList) { int ipt = 0; int atomMax =atomList.size(); for (int i = 0; i < atomMax; i++) if(atomList.get(i)) atoms[i].point3f.set(coordList[ipt++]) } Bob |
From: Bob H. <ha...@st...> - 2006-06-23 20:15:07
|
eric capps wrote: >On Jun 23, 2006, at 7:52 AM, Bob Hanson wrote: > > > >>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. >> >> > >bob, what is the purpose of the atomList variable here? in >particular, why are you using a BitSet? is it supposed to indicate >which coordinates are to be replaced? > > Right, this would be a simple compact way of indicating just the atoms you want changed without having to list all of them. > > >>>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. >> >> > >you're right, a script command isn't the best way. for my purposes >this would be in an applet context. new coordinates (i.e. calls to >this method) would be passed in either through javascript (and i >guess Jmol-new.js) or a separate java control applet. that's another >issue that is probably outside the scope of this topic, is it easy to >allow another embedded applet in the same page communicate with jmol? > > > OK, if it's applet, then the bitset idea is not so good. The best way would be to use something like I've already set up, where you change a specific atom's coordinate. But what is very slow is passing variables back and forth from JavaScript to the applet. So we have to come up with a mechanism of passing an array ONCE to do the job. JavaScript doesn't have bitsets, but Jmol does have the capability of turning any atom expression into a BitSet. Thus, we have in Viewer: BitSet getAtomBitSet(String atomExpression) { return selectionManager.getAtomBitSet(atomExpression); } My idea would be then, for the applet, something like: jmolSetAtomCoordinates("atomno<10",Coordinates) where "Coordinates" is an array of double[3] values, I think, defining the new coordinate. Maybe.... Right now I've implemented: public void setAtomCoord(int atomIndex, float x, float y, float z) { modelManager.setAtomCoord(atomIndex,x,y,z); } public void setAtomCoordRelative(int atomIndex, float x, float y, float z) { modelManager.setAtomCoordRelative(atomIndex,x,y,z); } (The second moves an atom by a cetain amount, not TO a certain place.) But we can't be calling this thousands of times. We need ONE call. We'll have to experiment to see how well Java can read JavaScript arrays. I suspect there's no problem. Bob |
From: eric c. <dif...@gm...> - 2006-06-23 21:07:02
|
On Jun 23, 2006, at 2:12 PM, Bob Hanson wrote: > OK, if it's applet, then the bitset idea is not so good. The best way > would be to use something like I've already set up, where you change a > specific atom's coordinate. But what is very slow is passing variables > back and forth from JavaScript to the applet. So we have to come up > with > a mechanism of passing an array ONCE to do the job. JavaScript doesn't > have bitsets, but Jmol does have the capability of turning any atom > expression into a BitSet. Thus, we have in Viewer: > > BitSet getAtomBitSet(String atomExpression) { > return selectionManager.getAtomBitSet(atomExpression); > } > > My idea would be then, for the applet, something like: > > jmolSetAtomCoordinates("atomno<10",Coordinates) > > where "Coordinates" is an array of double[3] values, I think, defining > the new coordinate. Maybe.... how powerful are atom expressions? i take it getAtomBitSet ("atomno<10") would return 1111111110...0 (in BitSet parameters of course); would an expression like atomno>5 && atomno<30 work? what about a wildcard? for that matter, it occurs to me that it may not even be necessary to use a BitSet, particularly if the majority of the atoms are changing coordinates. rather, we could have a method like: jmolSetAtomCoords(Double[] coords) and simply reallocate the atoms[] array to coordinates.length, then copy them in. would this not be quicker? this may also be helpful in the event that an atom is added or disappears. also, is there a reason to use doubles rather than floats? |
From: Bob H. <ha...@st...> - 2006-06-24 03:44:27
|
eric capps wrote: >how powerful are atom expressions? i take it getAtomBitSet >("atomno<10") would return 1111111110...0 (in BitSet parameters of >course); would an expression like atomno>5 && atomno<30 work? what >about a wildcard? > > > atom expressions can do anything. within(molecule,atomno=3) atomno < 10 and */1 you name it. >for that matter, it occurs to me that it may not even be necessary to >use a BitSet, particularly if the majority of the atoms are changing >coordinates. rather, we could have a method like: > >jmolSetAtomCoords(Double[] coords) > >and simply reallocate the atoms[] array to coordinates.length, then >copy them in. would this not be quicker? this may also be helpful in >the event that an atom is added or disappears. > > simple things like this are possible; the bitset idea or atom expression idea provides flexibility. If null, then it could certainly default to "replace all" but I thought we were interested in something that didn't necessarily replace all. >also, is there a reason to use doubles rather than floats? > > JavaScript apparently only as integers and doubles, and you have to FORCE it to use doubles. Even "1.0" is changed to an integer. So passed numeric variables from JavaScript to Java can't be floats. But we could pass a BitSet to JavaScript, have it load the bitset, and pass it back. This sort of thing is not out of the question: Viewer.Java: BitSet getBitSet() { return new BitSet(); } JavaScript: var myViewer = jmolGetPropertyAsJavaObject("jmolViewer") var myBitSet = myViewer.getBitSet(); myBitSet.set(3); myBitSet.set(5); myBitSet.set(6); jmolSetAtomCoordinates(myBitSet,....) Ah, actually, if we really wanted to play, we could have some fun with the following (if they were public): var atoms = jmolGetPropertyAsJavaObject("jmolViewer").getFrame().atoms Then right in the JavaScript set all the coordinates you want: for (var i = 0; i < atoms.length; i++) atoms[i].point3f.x = ... atoms[i].point3f.y = ... atoms[i].point3f.z = ... But that would be making an aweful lot public. Bob |
From: eric c. <dif...@gm...> - 2006-06-24 18:19:57
|
On Jun 23, 2006, at 10:49 PM, Bob Hanson wrote: > simple things like this are possible; the bitset idea or atom > expression > idea provides flexibility. If null, then it could certainly default to > "replace all" but I thought we were interested in something that > didn't > necessarily replace all. > true, something more generally applicable would be better. still, what about the case where an atom may be added or deleted? i suppose that at the beginning of the method we could have something like this: void replaceCoords(BitSet atomList, Point3f[] coordList) { int newAtomCount = atomList.size(); if (newAtomCount > atomCount) { for(int i = atomCount; i < newAtomCount; i++) { addAtom(); // the syntax for this method baffles me at the moment } atomCount = newAtomCount; } else if (newAtomCount < atomCount) { for(int i = atomCount - 1; i >= newAtomCount; i--) deleteAtom(i); atomCount = newAtomCount; } // rest of code } though clearly i don't understand all the fields of addAtom() yet. would this be the best way to go about this? |
From: Bob H. <ha...@st...> - 2006-06-24 22:01:43
|
eric capps wrote: >On Jun 23, 2006, at 10:49 PM, Bob Hanson wrote: > > >>simple things like this are possible; the bitset idea or atom >>expression >>idea provides flexibility. If null, then it could certainly default to >>"replace all" but I thought we were interested in something that >>didn't >>necessarily replace all. >> >> >> > >true, something more generally applicable would be better. still, >what about the case where an atom may be added or deleted? i suppose >that at the beginning of the method we could have something like this: > > > > void replaceCoords(BitSet atomList, Point3f[] coordList) { > int newAtomCount = atomList.size(); > if (newAtomCount > atomCount) { > for(int i = atomCount; i < newAtomCount; i++) { > addAtom(); // the syntax for this method baffles me at the >moment > } > atomCount = newAtomCount; > } > else if (newAtomCount < atomCount) { > for(int i = atomCount - 1; i >= newAtomCount; i--) > deleteAtom(i); > atomCount = newAtomCount; > } > // rest of code > } > >though clearly i don't understand all the fields of addAtom() yet. >would this be the best way to go about this? > > > I'm apprehensive about addAtom(). We'd have to think carefully about the effect of adding atoms. If at all possible, this should first be implemented only as a strict atom-coordinate replacement scheme. At first it may sound simple to add or remove atoms, but when you consider that the atom set may involve multiple models from multiple files, adding atoms may not be so simple. For example, there is nothing to date that flags an atom as deleted, but surely we don't want to shift the entire atom array because of a deletion. Adding and deleting atoms would have a profound effect on all sorts of things -- rasmol structures, bonds, polyhedra, anything that has an atom associated with it. Think hard about what exactly you want to be able to do. If there is any possibility that those added atoms might be already in place at the beginning of the animation and only displayed when needed, that would be far easier than trying to add them on the fly. Bob |
From: eric c. <dif...@gm...> - 2006-06-24 23:36:28
|
On Jun 24, 2006, at 5:06 PM, Bob Hanson wrote: > I'm apprehensive about addAtom(). We'd have to think carefully > about the > effect of adding atoms. If at all possible, this should first be > implemented only as a strict atom-coordinate replacement scheme. i had a feeling that a method with that many fields should not be invoked lightly. in the meantime i'll focus on just managing one-to- one replacements as you suggest, so as not to cause everything to violently explode. in fact, i think i may have something working already, but i have yet to test it thoroughly. if i do get somewhere, i'll put my code up here before getting anywhere near subversion. > At first it may sound simple to add or remove atoms, but when you > consider that the atom set may involve multiple models from multiple > files, adding atoms may not be so simple. For example, there is > nothing > to date that flags an atom as deleted, but surely we don't want to > shift > the entire atom array because of a deletion. Adding and deleting atoms > would have a profound effect on all sorts of things -- rasmol > structures, bonds, polyhedra, anything that has an atom associated > with it. > > Think hard about what exactly you want to be able to do. If there > is any > possibility that those added atoms might be already in place at the > beginning of the animation and only displayed when needed, that > would be > far easier than trying to add them on the fly. i do not believe that there is any guarantee about whether or how many atoms will come and go, but it seems to be a rare and fleeting event, so it's probably a pretty small number. i take it from your comment that there's probably some way to make atoms temporarily invisible? if so, for my purposes i could just add a few extra atoms to the first model to allow for this possibility and turn them on as necessary. way safer, it seems. does deleteAtom() have comparably catastrophic consequences? or does it just "hide" atoms? it is saturday and alliteration is my recreation. also rhyme. ok i'm done. |
From: Bob H. <ha...@st...> - 2006-06-25 14:24:41
|
eric capps wrote: > >does deleteAtom() have comparably catastrophic consequences? or does >it just "hide" atoms? > > > All you need to do to hide atoms is select (whateveratomstohide) wireframe off;spacefill off Bob |
From: eric c. <dif...@gm...> - 2006-06-25 17:07:22
|
On Jun 25, 2006, at 9:11 AM, Bob Hanson wrote: > All you need to do to hide atoms is > > select (whateveratomstohide) > wireframe off;spacefill off excellent. i'll whip up a test page today and we can check out how this thing behaves. |
From: eric c. <dif...@gm...> - 2006-06-25 23:51:54
|
it occurs to me, are we going to need to update bonds when this happens? i know very little about chemistry so i'm not too sure how this all works. so i've mucked around with everything a bit, and it seems to refresh coordinates rather well. one issue i've noticed is that i often have to move the model after i call the javascript method to actually display the changes. in fact, with the build i've made of your branch (what seems to be the latest), this same problem occurs in your setAtomCoord method. any ideas? |
From: Bob H. <ha...@st...> - 2006-06-26 00:44:42
|
eric capps wrote: >it occurs to me, are we going to need to update bonds when this >happens? i know very little about chemistry so i'm not too sure how >this all works. > >so i've mucked around with everything a bit, and it seems to refresh >coordinates rather well. one issue i've noticed is that i often have >to move the model after i call the javascript method to actually >display the changes. in fact, with the build i've made of your branch >(what seems to be the latest), this same problem occurs in your >setAtomCoord method. any ideas? > > > you need to invoke Viewer.refresh() manually using jmolGetPropertyAsJavaObject("jmolViewer").refresh() Or you can just use jmolScriptWait("") because a script automatically refreshes at the end. re: testing applet code: is there an easy way to debug the applet in a web context? i know that within eclipse you can launch it and set breakpoints and everything, but i'd like to be able to see how it responds to commands from Jmol.js without having to rebuild the jar everytime and be unable to set breakpoints. failing the ability to do this within eclipse, what other avenues can i take? is there, for example, an easy way to pass debugging information to the jmol console? --My method is decidely low tech and not necessarily to be recommended if someone else has a smarter approach: 1) I use Build.xml within Eclipse, including "clean" reordered before "main" if I've messed with JmolConstants or did anything that might affect any interface or just before an upload. This creates the Jar files in the main workspace directory. 2) I use the test HTML files you see in http://www.stolaf.edu/people/hansonr/jmol/test/proto to test all applet code. The idea here is to document all tests in relation to any particular topic so that I can run through them all quickly. I often find where I've broken one thing to fix another this way. 3) I have a little DOS batch file that copies the JAR files from the Eclipse workspace to my working HTML directory. I always call it "t.bat". So I do the build, and when I see "BUILD SUCCESSFUL" I exit the browser (otherwise any new JAR file is not loaded), switch to DOS, type "t", and I'm testing. Generous use of System.out.println(...) gives me the feedback I need. Also, the following script commands are useful: set debugScript set testFlag1 set testFlag2 set testFlag3 set testFlag4 Those test flags you can check using viewer.getTestFlag1(), ...2(), etc., so you can test different options if you want to. I realize this is back to the "no breakpoint" methods of yesteryear, but it works for me, and the HTML files I use for testing allow for very quick retesting of scripts, and also end up being demonstration pages, so I figure that makes up for the nuisance of no breakpoints. Bob |
From: eric c. <dif...@gm...> - 2006-06-26 17:37:18
|
On Jun 25, 2006, at 7:49 PM, Bob Hanson wrote: > you need to invoke Viewer.refresh() manually using > > jmolGetPropertyAsJavaObject("jmolViewer").refresh() > > Or you can just use > > jmolScriptWait("") > > because a script automatically refreshes at the end. ah i see. i was hoping it was something simple like that. > --My method is decidely low tech and not necessarily to be > recommended if someone else has a smarter approach: > > 1) I use Build.xml within Eclipse, including "clean" reordered > before "main" if I've messed with JmolConstants or did anything > that might affect any interface or just before an upload. This > creates the Jar files in the main workspace directory. > > 2) I use the test HTML files you see in http://www.stolaf.edu/ > people/hansonr/jmol/test/proto to test all applet code. The idea > here is to document all tests in relation to any particular topic > so that I can run through them all quickly. I often find where I've > broken one thing to fix another this way. > > 3) I have a little DOS batch file that copies the JAR files from > the Eclipse workspace to my working HTML directory. I always call > it "t.bat". > > So I do the build, and when I see "BUILD SUCCESSFUL" I exit the > browser (otherwise any new JAR file is not loaded), switch to DOS, > type "t", and I'm testing. > > Generous use of > > System.out.println(...) > > gives me the feedback I need. Also, the following script commands > are useful: > > set debugScript > set testFlag1 > set testFlag2 > set testFlag3 > set testFlag4 > > Those test flags you can check using viewer.getTestFlag1(), ...2(), > etc., so you can test different options if you want to. > > I realize this is back to the "no breakpoint" methods of > yesteryear, but it works for me, and the HTML files I use for > testing allow for very quick retesting of scripts, and also end up > being demonstration pages, so I figure that makes up for the > nuisance of no breakpoints. no, that's rather useful actually. it reminds me of junit. if you're ever curious, there's a way to add breakpoints to applets embedded in pages, which i discovered after my request for help. particularly useful if you can tell what is breaking but not why. also, what about bonds? are those going to need to be updated as well when atom coordinates are changed? is there anything else like this that might? |
From: Bob H. <ha...@st...> - 2006-06-26 18:09:46
|
eric capps wrote: > > if you're ever curious, there's a way to add breakpoints to applets > embedded in pages, which i discovered after my request for help. > particularly useful if you can tell what is breaking but not why. I'd be interested in that. How does it work? > > also, what about bonds? are those going to need to be updated as well > when atom coordinates are changed? is there anything else like this > that might? The presumption here is that bonds are not changing. If you also want to change bonding, you can either do that yourself manually using the connect script or have Jmol redo all bonding automatically -- but that will slow things down. Bob |
From: eric c. <dif...@gm...> - 2006-06-27 19:10:45
|
On Jun 26, 2006, at 1:09 PM, Bob Hanson wrote: > I'd be interested in that. How does it work? basically you have to 1) set up a separate eclipse environment to debug it and 2) configure the applet runtime parameters of your java plug-in. 1) go to run > debug..., and start a new debug environment under "remote java application". you can leave it at localhost and 8000 if you're doing this all on your own computer. 2) this page will tell you a good bit: http://java.sun.com/j2se/1.5.0/ docs/guide/plugin/developer_guide/debugger.html. the command line parameters they specified didn't work for me, however. if they don't work for you, this is what i used instead: -Xdebug - Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n. after this, basically all you need to do is open the page in your favorite browser, make sure the applet has loaded, then select and start the debugging environment you created in eclipse. if you don't get an error, it's working, and any breakpoints you have set in your code will be, well, functional. i used this to see how 2d arrays of doubles are passed between javascript and java, and hopefully you will have some other use for it too. if you need any more help with this just let me know. > The presumption here is that bonds are not changing. If you also want > to change bonding, you can either do that yourself manually using the > connect script or have Jmol redo all bonding automatically -- but that > will slow things down. i honestly don't know whether or not this is something i need to consider. if it is, is there anything simple like a refreshBonds() method? or is that something extra i may have to write? |
From: eric c. <dif...@gm...> - 2006-07-16 23:46:28
|
On Jun 26, 2006, at 1:09 PM, Bob Hanson wrote: > The presumption here is that bonds are not changing. If you also want > to change bonding, you can either do that yourself manually using the > connect script or have Jmol redo all bonding automatically -- but that > will slow things down. Does the rebond() method of the Viewer class do this correctly? |
From: Bob H. <ha...@st...> - 2006-07-18 00:16:57
|
eric capps wrote: >On Jun 26, 2006, at 1:09 PM, Bob Hanson wrote: > > >>The presumption here is that bonds are not changing. If you also want >>to change bonding, you can either do that yourself manually using the >>connect script or have Jmol redo all bonding automatically -- but that >>will slow things down. >> >> > >Does the rebond() method of the Viewer class do this correctly? > > yes, altough it deletes ALL the bonds and then starts again. Frame.rebond(boolean deleteFirst) allows for carrying over old bonds. So how's the animation idea going? bob |
From: eric c. <dif...@gm...> - 2006-07-18 00:39:03
|
On Jul 17, 2006, at 7:17 PM, Bob Hanson wrote: > > yes, altough it deletes ALL the bonds and then starts again. > Frame.rebond(boolean deleteFirst) allows for carrying over old bonds. Not sure I understand entirely (truth be told I don't know so much about chemistry). Is this accurate? I assume its faster. > So how's the animation idea going? > > bob > Rather well, thanks for asking! I actually already have a rudimentary modification of Jmol working that I'd be happy to show you when I iron a few things out, if you think there's any functionality you may be able to pull from there. I ended up writing much of it in a separate applet and passing it through the Jmol javascript, for fear of breaking anything, but it could probably be incorporated into the Jmol code fairly easily with a little help. -Eric |
From: eric c. <dif...@gm...> - 2006-07-18 19:38:25
|
On Jul 17, 2006, at 7:17 PM, Bob Hanson wrote: > > yes, altough it deletes ALL the bonds and then starts again. > Frame.rebond(boolean deleteFirst) allows for carrying over old bonds. I also notice that the rebond(boolean) method is not written into the Viewer or ModelManager code, is there a reason for this? Would anything bad happen if I did stitch it in? |
From: Bob H. <ha...@st...> - 2006-07-18 23:34:04
|
It can be there. Go ahead. eric capps wrote: >On Jul 17, 2006, at 7:17 PM, Bob Hanson wrote: > > >>yes, altough it deletes ALL the bonds and then starts again. >>Frame.rebond(boolean deleteFirst) allows for carrying over old bonds. >> >> > >I also notice that the rebond(boolean) method is not written into the >Viewer or ModelManager code, is there a reason for this? Would >anything bad happen if I did stitch it in? > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Jmol-developers mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-developers > > |