From: Miguel <mt...@mt...> - 2003-10-29 15:19:11
|
> Just discovered, downloaded and spent a few hours playing with > Jmol-8/JmolApplet-8 and the =91sneak preview=92 of Jmol-10. ABSOLUTELY > BRILLIANT=21 Glad that you like Jmol > The materials I have been working on have been mainly targeted at > pre-university level (AS and A2 level in UK edu-speak) and involve > inorganic crystal and metal structures as well as organic molecules > and biopolymers. All currently use .pdb format. Phillip Barak of the University of Wisconsin USA recently sent me a link that shows some excellent web pages with inorganic molecules. You should take a look at them: http://www.soils.wisc.edu/virtual_museum/ > In this context, I have the > following wish list for RasMol/Chime scripting and other options in > the forthcoming Jmol/JmolApplet releases. > > > 1. set unitcell on/off > > It would be good to be able to display the unit cell when > crystallographic data is present in .pdb files. As set axes and set > boundbox are already implemented I presume this would not be too > difficult. In my experience, the rendering of the unit cell in > RasMol/Chime was imperfect, particularly when it intersected atom > spheres at the corners of a unit cell, so it would be nice if this was > done =91properly=92 in Jmol. This is a bug ... good catch. The Jmol application currently supports unit cell display. But the comman= d was not implemented in the script interpreter. Several of the other Jmol developers are crystalographers, so I suspect more of the 'crystal' functionality will make it into the scripting language over time. > 2. set connect false/save (and initscript parameter) > > For complex structures RasMol and Chime usually ignore CONECT records > in .pdb files and use their own internal algorithms to determine > bonds. This means that structures with =91unusual=92 bond lengths, e.g.= > ionic and metal lattices, may not display correctly even if the bonds > are > described by CONECT records. Further explanation and details can be > obtained from: > > http://www.umass.edu/microbio/rasmol/rasbonds.htm > > The workaround for this in RasMol 2.6 (not sure about RasMol 2.7) and > Chime 2 is provided by the set connect false command which forces use > of the CONECT records. In addition Chime 2 has the set connect save > command which forces the plugin to show bonds for all CONECT records > in the .pdb file, while at the same time calculating bonds not > specified in the CONECT records in the usual manner. Set connect save > can also be issued in the embed tag which invokes Chime 2 using the > initscript parameter. Initscript is required to execute the command > before the molecule is loaded. > > It would be nice if the JmolApplet would implement set connect > false/save with initscript, or some equivalent mechanism, to achieve > the display of structures with =91unusual=92 and heterogeneous bond > lengths. Not sure what you mean by 'initscript' ... I have no practical experience= using either Chime or RasMol :-) Also, I was unable to find any reference in the RasMol doc to 'set connect' Is this a Chime extension? Or is it just undocumented? Jmol respects atom connectiving in .mol files, but I think it currently ignores CONECT records in .pdb files ... this needs to be implemented. The RasMol doc talks about using two different algorithms for small vs. large molecules. Jmol doesn't do this. We have one algorithm that (we think) is pretty fast. The rules for bonding are (generally) taken from OpenBabel ... and I *think* it does a better job with metals than RasMol ... the iron in hemoglobin hemes is correctly bonded in Jmol but is not bonded at all in RasMol. Specific examples of molecules that are not bonding properly would be helpful. With that said, clearly we need to implement the 'set connect' behavior you are describing so that we respect CONECT records when they are presen= t > 3. scaled > > Chime includes the scale3d embed tag. When the same scale3d value is > used for multiple structure windows on a page, the viewer can compare > the relative size of the structures. I find this very useful for > visualising, for example, trends in atomic/ionic/metallic radii and > bond lengths. Good. > 4. Alternative units (pm and/or nm) for displaying distances (in > addition to =C5) > > In common with most molecular display programs, Jmol, RasMol & Chime > use =C5 as the unit of distance measurement. Although the =C5ngstr=F6m= is > the =91natural=92 unit for bond lengths, SI units are recommended for > pre-university students in the UK. Hence these students tend to > encounter bond lengths measured in pm (or nm) in most textbooks, exam > papers etc. I certainly don=92t want to start a long thread discussing > the relative merits of different units or at what point in their > education students should be introduced to the =C5. However, from my > point of view, it would be good to have some mechanism for switching > to different units (pm) for distance measurements, with perhaps =C5 as > the default. > > Of course, I am also looking forward to all the protein rendering > options and other goodies promised for Jmol-10. Again, thanks for all > your efforts. Seems like an OK idea to me. My only reservation is that we need to find a way to add this control without adding too many changes to the scripting language. To date I have been reluctant to implement commands outside the RasMol/Chime set. In the future we will clearly have to do so, but I want= to get some end-user input before we start adding additional scripting commands. Thank you *very* much for taking the time to write this. We find this typ= e of list quite helpful. All of these items have been added to our bug database on sourceforge. Miguel > Geoff Rowland > > geoff.rowland=40yeovil.ac.uk |
From: PHILLIP W B. <pw...@fa...> - 2003-10-29 17:23:24
|
----- Original Message ----- From: Miguel <mt...@mt...> Date: Wednesday, October 29, 2003 9:19 am Subject: Re: [Jmol-users] JmolApplet Wish List > > Just discovered, downloaded and spent a few hours playing with > > Jmol-8/JmolApplet-8 and the ?sneak preview? of Jmol-10. ABSOLUTELY > > BRILLIANT! > Glad that you like Jmol > > > The materials I have been working on have been mainly targeted at > > pre-university level (AS and A2 level in UK edu-speak) and involve > > inorganic crystal and metal structures as well as organic molecules > > and biopolymers. All currently use .pdb format. > > Phillip Barak of the University of Wisconsin USA recently sent me > a link > that shows some excellent web pages with inorganic molecules. You > shouldtake a look at them: > http://www.soils.wisc.edu/virtual_museum/ Just to jump in here about our use of pdb files for the minerals on our site: Using pdb was not our first choice. We would have prefered CIF format, files with the barest minimum of spatial information, since symmetry operators allow 'tiling' out in any direction per user parameters, but that was not to be with Chime. (WebLab viewer did a nice job of asking how many cells in each direction and then drawing it up.) Then of course, we found that Rasmol/Chime didn't do a very good job of connecting bonds (allowing Si-Si bonds and Si-Al bonds when it should have been Si-O-Si or Si-O-Al.) And Chime never seemed to get the unit cell drawn correctly. For a while, we used mol format, with bonds specified, but the number of atoms was too limited for any but the smallest mineral models. We moved on to pdb files, with positions and bonds specified, and some of these models require relatively large files. This works well but quite a bit of spacially redundant information is included in the pdb or mol file. --Phil Barak |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-29 19:18:16
|
On Wednesday 29 October 2003 18:23, PHILLIP W BARAK wrote: > > > Just discovered, downloaded and spent a few hours playing with > > > Jmol-8/JmolApplet-8 and the ?sneak preview? of Jmol-10. ABSOLUTELY > > > BRILLIANT! > > > > Glad that you like Jmol > > > > > The materials I have been working on have been mainly targeted at > > > pre-university level (AS and A2 level in UK edu-speak) and involve > > > inorganic crystal and metal structures as well as organic molecules > > > and biopolymers. All currently use .pdb format. > > > > Phillip Barak of the University of Wisconsin USA recently sent me > > a link > > that shows some excellent web pages with inorganic molecules. You > > shouldtake a look at them: > > http://www.soils.wisc.edu/virtual_museum/ > > Just to jump in here about our use of pdb files for the minerals on our > site: > > Using pdb was not our first choice. We would have prefered CIF format, > files with the barest minimum of spatial information, since symmetry > operators allow 'tiling' out in any direction per user parameters, but that > was not to be with Chime. Jmol v8 has very limited support for PDB files... it reads only the atomic coordinates and the unit cell parameters, and symmetry operations are not yet supported... I am not sure what you mean with tiling, but what would the CIF file that would define the 'tiling' look like? Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Miguel <mt...@mt...> - 2003-10-29 20:17:21
|
> Miguel wrote: > [Praise for JMol's bonding algorithm, and a request for > molecules not rendered properly] I apologize ... I certainly didn't mean to come across as 'praising' the Jmol bonding algorithm. I tried to make clear that the bonding criteria are taken from OpenBabel. The 'praise' I gave it was that it was 'pretty fast' ... I'll accept full responsibility for that. > It is a while ago, and I am no longer working on that project, > but you might remember me asking something similar in 2000. I only started working on Jmol code in 2003. > Out of sentimentality, I'm still lurking. I used an old version > of the JMol Applet in a Java application I developed, and tried > to make you aware of the fact that sometimes people calculate > their own structures, complete with "final" bond and atom position > information, and don't want a viewer program trying to be smart > and decide where atoms and bonds should be. Certainly I agree 100%. What I believe I said in my email was: - we use the connectivity in .mol files - we *need* to use the CONECT records in .pdb files > Did I ever report back when I finished my project? You can see > the results at "http://www.mathematik.uni-bielefeld.de/~CaGe/". > On the website, we praise JMol because the version we have does > exactly what we want, but I don't know if that would still be > true in the current version. Your web application would certainly need some modifications to run with the current version of Jmol. Probably over 90% of the Jmol code has been rewritten this year ... 100% of the applet code. In the course of this we have explicitly dropped some functionality from previous versions (like rendering styles). > My point is, I didn't get all I wanted from a standard version > of the JMol Applet, so I ended up changing bits of the source > code myself, using CML data with a new "Convention" of "MathGraph". I > sent messages about my changes, but these seemed to get lost > in the activies of JMol development. As I said, I only started working on the project this year. If I missed a message of yours, then I apologize. I assure you, I *want* end-user feedback. > It would be good if a > position such as mine wasn't completely forgotten. From that > perspective, Miguel's response is not to the point. I am truly sorry if my response came across as 'arrogant' or not to the point. > My specific requirements were: > * Exact representation of input data in terms of atom positions > and bonds (Sometimes our bonds even were "impossible" from a > chemistry point of view, but I still wanted JMol to faithfully show > what it was given to show.) I agree 100% > I also needed this to be > possible in CML, since that was the only format one could hand to > the applet in a parameter. There was no scripting back then. > * getter and setter methods for display settings (things like > the drawing modes that existed back then) It isn't clear to me exactly what you are looking for, but I believe that most of the this type of functionality should be available through the scripting language today. > I dreamed of being able to always take the newest version and > "plug it in" to my application, and I'd wonder if that could be > made possible. > > Sebastian Lisken Sounds like you may have had some negative experiences with Jmol in the past. There will be a major code base change with the upcoming v10 release. Stability seems important to you. Therefore, I suggest you wait for the Jmol v10 release and reevaluate it when it comes out. It it doesn't meet your needs, then please let us know and we will add your requirements to the list. Miguel |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-30 07:57:20
|
On Wednesday 29 October 2003 21:17, Miguel wrote: > > It is a while ago, and I am no longer working on that project, > > but you might remember me asking something similar in 2000. > > I only started working on Jmol code in 2003. I should know, but I can't remember... Jmol is not the only thing I work on, and I tend to forget things I'm not working on fulltime... nothing personal. > > Out of sentimentality, I'm still lurking. I used an old version > > of the JMol Applet in a Java application I developed, and tried > > to make you aware of the fact that sometimes people calculate > > their own structures, complete with "final" bond and atom position > > information, and don't want a viewer program trying to be smart > > and decide where atoms and bonds should be. > > Certainly I agree 100%. Someone else also commented on this last week... Let me make clear that Jmol *does* have support for turning off automatic rebonding... Or did have. It might have gotten buried in all the recent work, but taking bond information from files is/has been available in Jmol. > What I believe I said in my email was: > - we use the connectivity in .mol files Indeed. > - we *need* to use the CONECT records in .pdb files It did... look in the cvs logs for the PDBReader, and you'll find that is was added at some stage, but removed later again, because the code was then not considered stable enough. > > Did I ever report back when I finished my project? You can see > > the results at "http://www.mathematik.uni-bielefeld.de/~CaGe/". > > On the website, we praise JMol because the version we have does > > exactly what we want, but I don't know if that would still be > > true in the current version. What patches did you apply to make it 'leaner'? BTW, did you send those back to the Jmol project? I'm very interested in getting them (in some form) back into the main program... > Your web application would certainly need some modifications to run with > the current version of Jmol. > Probably over 90% of the Jmol code has been rewritten this year ... 100% > of the applet code. In the course of this we have explicitly dropped some > functionality from previous versions (like rendering styles). > > > My point is, I didn't get all I wanted from a standard version > > of the JMol Applet, so I ended up changing bits of the source > > code myself, using CML data with a new "Convention" of "MathGraph". I > > sent messages about my changes, but these seemed to get lost > > in the activies of JMol development. My apologies for that. Could you please resend them? > As I said, I only started working on the project this year. > If I missed a message of yours, then I apologize. > > I assure you, I *want* end-user feedback. > > > It would be good if a > > position such as mine wasn't completely forgotten. From that > > perspective, Miguel's response is not to the point. > > I am truly sorry if my response came across as 'arrogant' or not to the > point. Sebastian, please consider that the project is currently run by only two people. One of these (me) actually has a full time job next to it... It thus is very hard to give attention to all points of improvement of Jmol, and to not forget things... Ideally, things don't get forgotten, but this is very difficult with the small developers base Jmol has at this moment. > > My specific requirements were: > > * Exact representation of input data in terms of atom positions > > and bonds (Sometimes our bonds even were "impossible" from a > > chemistry point of view, but I still wanted JMol to faithfully show > > what it was given to show.) > > I agree 100% > > > I also needed this to be > > possible in CML, since that was the only format one could hand to > > the applet in a parameter. There was no scripting back then. > > > > * getter and setter methods for display settings (things like > > the drawing modes that existed back then) > > It isn't clear to me exactly what you are looking for, but I believe that > most of the this type of functionality should be available through the > scripting language today. > > > I dreamed of being able to always take the newest version and > > "plug it in" to my application, and I'd wonder if that could be > > made possible. > > > > Sebastian Lisken > > Sounds like you may have had some negative experiences with Jmol in the > past. > > There will be a major code base change with the upcoming v10 release. > Stability seems important to you. Therefore, I suggest you wait for the > Jmol v10 release and reevaluate it when it comes out. It it doesn't meet > your needs, then please let us know and we will add your requirements to > the list. Likewise. kind regards, Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Sebastian L. <seb...@un...> - 2003-10-30 09:33:40
|
Hi again - apologies if my email came over as a complaint. I was very happy with Jmol and with the support I got from people, including Egon, at the time. I did submit changes to Jmol to the list, and interest was expressed, and when I say that these changes got lost I meant that development of the program went into other directions. And though I was working on a current version at the time I started, when I was ready to submit my changes I think similar things had already been done in a different way. The changes I made to the "core" of Jmol involved creating a structure for storing bonds, which was not there at the time, I think - they were calculated automatically and not stored before rendering. I also found a bug that caused every bond to be painted twice. In theoretical terms, the code was going through all fields of the (symmetric) connection matrix when all that was needed was the upper (or lower) triangle. I seem to remember having to consider the order atoms and bonds were painted as well. But these are vague memories, and I'm certain all those issues are irrevelant by now. In theory, it should be possible to incorporate a new version of Jmol into CaGe, and in my previous email I tried to define the interface that would be needed. In practice, such a thing is not likely to happen, but I remain interested because of the amazing development he applet seems to have had. My message mainly was about not forgetting my requirements, when I saw that others may have similar ones. I didn't see any arrogance coming from the developers, neither then or now, and I fully understand the resource limits. You're doing great work. Just wanted to point out that relying and possibly improving the applet's "smartness" in terms of bonds and positions may not be all that users want. Sebastian |
From: Miguel <mt...@mt...> - 2003-10-30 10:13:49
|
> My message mainly was about not forgetting my requirements, > when I saw that others may have similar ones. > ... > Just wanted to point out that relying and possibly > improving the applet's "smartness" in terms of bonds and > positions may not be all that users want. You are absolutely right. If the connectivity information is in the file then we need to use what is there. It is on the bug list for .pdb files Miguel |
From: Sebastian L. <seb...@un...> - 2003-11-04 10:22:42
Attachments:
buckyball.cml
unchemical.cml
|
Hi again, the recent discussion I joined was about .pdb files and the "set connect" script command. Miguel said that when there is bond information in a file, Jmol should stick to it, and I wonder if this would apply to all formats. Back in the days of CaGe development, the suggestion was made to indicate in a molecule convention that the data should be taken "as is", even in the case of "unchemical" molecules. I got a colleague who is still working with CaGe to send me two samples of the CML format that I made our program send to the Jmol applet. Note the "convention" in the third lines. I wonder what a current version of the applet would make of them? What the display should be with the "unchemical" file I don't know, I'm afraid - this is not a question of the "what do you see" style but rather one for the developers: what would Jmol make of the data in these files, and would you be willing to make it adhere strictly to the bonds and atom positions? Sebastian |
From: timothy d. <mol...@ma...> - 2003-11-04 11:07:44
|
at 11:22 am EDT on (Tuesday) 4 November 2003 Sebastian Lisken said: > Hi again, the recent discussion I joined was about .pdb files and > the "set connect" script command. Miguel said that when there is > bond information in a file, Jmol should stick to it, and I wonder > if this would apply to all formats. Back in the days of CaGe > development, the suggestion was made to indicate in a molecule > convention that the data should be taken "as is", even in the > case of "unchemical" molecules. > hi Sebastian, my 2c: I have always believed that data should be stored in the data file, and not in the software. if you want to create an "unchemical" molecule, rendering software should not second-guess you. of course, that might give rise to strange and funky results, but data files are much easier to "fix" than software. that being said, I do support software applying default rules in the absence of data from a file. I just don't think it should override. I don't know enough about JMol yet to know what it does, but I cc'd your message to the developer list. regards, :tim -- timothy driscoll molvisions - molecular graphics & visualization <http://www.molvisions.com/> usa:north carolina:wake forest > I got a colleague who is still working with CaGe to send me two > samples of the CML format that I made our program send to the Jmol > applet. Note the "convention" in the third lines. I wonder what a > current version of the applet would make of them? What the display > should be with the "unchemical" file I don't know, I'm afraid - this > is not a question of the "what do you see" style but rather one > for the developers: what would Jmol make of the data in these > files, and would you be willing to make it adhere strictly to the > bonds and atom positions? > > Sebastian > > > ----- > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE molecule SYSTEM "cml.dtd" []> > <molecule convention="MathGraph"> > <atomArray> > <stringArray builtin="id">a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 > a15 a16 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 a32 a33 > a34 a35 a36 a37 a38 a39 a40 a41 a42 a43 a44 a45 a46 a47 a48 a49 a50 a51 a52 > a53 a54 a55 a56 a57 a58 a59 a60</stringArray> > <stringArray builtin="elementType">C C C C C C C C C C C C C C C C C C C C > C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C > C</stringArray> > <floatArray builtin="x3">-3.17 -3.182 -3.186 -2.388 -1.581 -0.277 0.537 > 1.848 2.358 3.171 3.182 3.186 2.388 1.581 0.277 -0.537 -1.848 -2.358 -3.162 > -2.345 -1.53 -0.22 0.587 1.891 2.382 1.57 1.558 0.247 -0.264 -1.572 -2.371 > -3.177 -3.165 -2.351 -1.534 -0.225 0.266 -0.552 -1.86 -2.382 -1.891 -0.587 > 0.22 1.53 2.345 3.162 3.166 3.177 2.371 1.572 0.264 -0.247 -1.558 -1.57 -0.266 > 0.225 1.534 2.351 1.86 0.551</floatArray> > <floatArray builtin="y3">-1.401 -0.799 0.596 0.946 2.089 2.052 2.822 2.413 > 2.517 1.401 0.799 -0.596 -0.946 -2.089 -2.052 -2.822 -2.413 -2.517 -0.608 > -1.233 -0.463 -0.872 0.271 0.234 1.312 2.428 3.03 3.439 3.335 2.882 2.533 1.39 > 0.788 1.558 0.933 1.386 2.465 3.09 2.637 -1.312 -0.234 -0.271 0.872 0.463 > 1.233 0.608 -0.788 -1.39 -2.533 -2.882 -3.335 -3.439 -3.03 -2.428 -2.465 > -1.386 -0.933 -1.558 -2.637 -3.09</floatArray> > <floatArray builtin="z3">0.138 -1.126 -1.237 -2.332 -2.275 -2.784 -1.945 > -1.673 -0.374 -0.138 1.126 1.237 2.332 2.275 2.784 1.945 1.673 0.374 1.291 > 2.24 3.079 3.351 3.409 2.899 2.154 1.918 0.654 0.382 -0.918 -1.121 -0.026 > -0.083 1.181 2.019 2.969 3.172 2.427 1.478 1.274 -2.154 -2.899 -3.409 -3.351 > -3.079 -2.24 -1.291 -1.181 0.083 0.026 1.121 0.918 -0.382 -0.654 -1.918 -2.427 > -3.172 -2.968 -2.019 -1.274 -1.478</floatArray> > </atomArray> > <bondArray> > <stringArray builtin="atomRef">a1 a1 a1 a2 a2 a3 a3 a4 a4 a5 a5 a6 a6 a7 > a7 a8 a8 a9 a9 a10 a10 a11 a11 a12 a12 a13 a13 a14 a14 a15 a15 a16 a16 a17 a17 > a18 a19 a19 a20 a21 a21 a22 a23 a23 a24 a25 a26 a26 a27 a28 a28 a29 a30 a31 > a31 a32 a33 a34 a34 a35 a36 a37 a38 a40 a40 a41 a42 a42 a43 a44 a44 a45 a46 > a47 a47 a48 a49 a49 a50 a51 a52 a52 a53 a54 a55 a55 a56 a57 a58 > a59</stringArray> > <stringArray builtin="atomRef">a18 a19 a2 a3 a40 a32 a4 a5 a41 a30 a6 a7 > a43 a29 a8 a9 a45 a27 a10 a11 a46 a25 a12 a13 a48 a24 a14 a15 a50 a22 a16 a17 > a51 a20 a18 a53 a20 a33 a21 a22 a35 a23 a24 a36 a25 a26 a27 a37 a28 a29 a38 > a30 a31 a32 a39 a33 a34 a35 a39 a36 a37 a38 a39 a41 a54 a42 a43 a56 a44 a45 > a57 a46 a47 a48 a58 a49 a50 a59 a51 a52 a53 a60 a54 a55 a56 a60 a57 a58 a59 > a60</stringArray> > </bondArray> > </molecule> > > ----- > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE molecule SYSTEM "cml.dtd" []> > <molecule convention="MathGraph"> > <atomArray> > <stringArray builtin="id">a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 > a15 a16 a17 a18 a19</stringArray> > <stringArray builtin="elementType">X X C X C Si Si X X C Si S C X C Si C C > Si</stringArray> > <floatArray builtin="x3">-0.51 -0.242 -0.454 -1.19 -0.474 -1.315 -1.296 > -0.371 0.503 0.433 0.453 0.544 0.431 0.475 0.391 -0.458 0.455 1.331 > 1.293</floatArray> > <floatArray builtin="y3">-0.878 0.042 -0.767 -0.529 -0.687 0.216 0.461 > 0.731 -0.716 -1.634 -1.217 -0.321 1.071 1.058 1.476 1.191 0.291 0.114 > 0.098</floatArray> > <floatArray builtin="z3">-0.36 0.931 1.034 0.24 -1.099 -0.681 0.364 -0.857 > -0.687 0.077 1.135 1.282 1.211 -0.036 -0.776 0.085 -1.589 -0.388 > 0.114</floatArray> > </atomArray> > <bondArray> > <stringArray builtin="atomRef">a1 a1 a1 a1 a1 a1 a1 a1 a2 a2 a2 a2 a2 a2 > a2 a2 a2 a2 a2 a3 a4 a4 a4 a4 a4 a5 a6 a7 a8 a8 a8 a8 a8 a9 a9 a9 a9 a9 a9 a9 > a10 a11 a12 a12 a12 a13 a14 a14 a14 a15 a18</stringArray> > <stringArray builtin="atomRef">a2 a3 a4 a5 a6 a7 a8 a9 a9 a10 a11 a12 a13 > a14 a8 a15 a16 a4 a3 a4 a16 a8 a7 a6 a5 a6 a7 a8 a16 a15 a14 a17 a9 a17 a14 > a18 a19 a12 a11 a10 a11 a12 a19 a14 a13 a14 a19 a18 a17 a16 a19</stringArray> > </bondArray> > </molecule> |
From: Peter Murray-R. <pm...@ca...> - 2003-11-04 20:30:07
|
At 06:07 04/11/2003 -0500, timothy driscoll wrote: >at 11:22 am EDT on (Tuesday) 4 November 2003 Sebastian Lisken said: > > > Hi again, the recent discussion I joined was about .pdb files and > > the "set connect" script command. Miguel said that when there is > > bond information in a file, Jmol should stick to it, and I wonder > > if this would apply to all formats. Back in the days of CaGe > > development, the suggestion was made to indicate in a molecule > > convention that the data should be taken "as is", even in the > > case of "unchemical" molecules. > > In CML we feel strongly that what the author specifies is what the content is. There are certain obvious errors (bonds referring to non-existent atoms or negative hydrogenCount) but everything else is "valid". One reason for this is that it could be an *example* of an unacceptable or unstable molecule. Many program "add" information - Jmol will add bonds if atoms are within a certain distance or will relocate atoms within a crystallographic unit cell. I personally argue against this as there may be good reasons not to. At least there need to be controls that the user can set so that these default actions do not occur. I think Jmol may have some of those but I can't find them on the menu. We are trying to work towards a system in CML where programs actively add metadata on the information it has added. Then a consumer could decide what had been changed and whether they wish to reverse it. P. BTW I see nothing wrong in the CML files attached. > > I got a colleague who is still working with CaGe to send me two > > samples of the CML format that I made our program send to the Jmol > > applet. Note the "convention" in the third lines. This is perfectly acceptable. However software need not take any action on this. We hope that an agreed set of conventions will arise. In this case I don't think it's necessary as the molecule is CML-valid. > I wonder what a > > current version of the applet would make of them? What the display > > should be with the "unchemical" file I don't know, I'm afraid - this > > is not a question of the "what do you see" style but rather one > > for the developers: what would Jmol make of the data in these > > files, and would you be willing to make it adhere strictly to the > > bonds and atom positions? > > > > Sebastian |
From: E.L. W. <eg...@sc...> - 2003-11-04 12:53:24
|
On Tuesday 04 November 2003 11:22, Sebastian Lisken wrote: > Hi again, the recent discussion I joined was about .pdb files and > the "set connect" script command. Miguel said that when there is > bond information in a file, Jmol should stick to it, and I wonder > if this would apply to all formats. Back in the days of CaGe > development, the suggestion was made to indicate in a molecule > convention that the data should be taken "as is", even in the > case of "unchemical" molecules. > > I got a colleague who is still working with CaGe to send me two > samples of the CML format that I made our program send to the Jmol > applet. Note the "convention" in the third lines. I wonder what a > current version of the applet would make of them? What the display > should be with the "unchemical" file I don't know, I'm afraid - this > is not a question of the "what do you see" style but rather one > for the developers: what would Jmol make of the data in these > files, and would you be willing to make it adhere strictly to the > bonds and atom positions? It looks like proper CML1... (and it is valid according to the CML1 DTD) So, it should work, but it is not... bonds are not read, so Jmol thinks the file does not have bonds... this is a bug in the CMLReader... I guess a similar thing is happening with the unchemical.cml... Can these two files be put in CVS for testing purposes? Egon -- eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 |
From: Sebastian L. <lisken@Mathematik.uni-bielefeld.de> - 2003-11-04 13:55:20
|
> It looks like proper CML1... (and it is valid according to the CML1 DTD) > So, it should work, but it is not... bonds are not read, so Jmol thinks the > file does not have bonds... this is a bug in the CMLReader... It's adapted from some CML that the old version of the applet did read, and now I seem to remember that I had to add reading bonds to the CMLReader myself. I seem to have mislaid the sources for that, unfortunately, but as I had to make up my own bonds structure and Jmol now does have its own (all from vague memory), this shouldn't be too great a loss. Sebastian |
From: E.L. W. <eg...@sc...> - 2003-11-04 15:23:11
|
On Tuesday 04 November 2003 14:55, Sebastian Lisken wrote: > > It looks like proper CML1... (and it is valid according to the CML1 DTD) > > So, it should work, but it is not... bonds are not read, so Jmol thinks > > the file does not have bonds... this is a bug in the CMLReader... > > It's adapted from some CML that the old version of the applet > did read, and now I seem to remember that I had to add reading > bonds to the CMLReader myself. I seem to have mislaid the > sources for that, unfortunately, but as I had to make up my > own bonds structure and Jmol now does have its own (all from > vague memory), this shouldn't be too great a loss. I think the main problem is that the files don't define bond orders... I don't think the CML IO can deal with that situation... I see if I can fix that. BTW, the file could better use CML2 format, which solves a number of problems with the CML1 format... Egon -- eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 |
From: Sebastian L. <lisken@Mathematik.uni-bielefeld.de> - 2003-11-04 15:36:24
|
[Egon points out that CML2 could be better] If there's a variant of CML where I could specify bonds even if don't know bond orders, my particular requirements would be met. Assuming, as Miguel is pointing out, that Jmol would stick to that information as soon as it appears in the CML file. Pointers to examples would be appreciated. Just one issue - getter and setter method for the applets display settings would be good. I don't need to know any internal properties, just the ability to retrieve an object and later pass it to a new instance of the applet. If the new versions still have display settings, that is. Sebastian P.S.: There's no need to send copies to me. I still read jmol-users, that's how I could join that discussion. ;-) |
From: Miguel <mt...@mt...> - 2003-11-04 18:46:15
|
> Just one issue - getter and setter method for the applets > display settings would be good. It is not clear to me what level you are referring to ... JavaScript code using the standard applet or Java code embedded into a 'custom' applet. Using JavaScript: Almost all attributes can be set through the scripting language. There currently are no 'getter' methods. Using Java: All attributes are available for getting and setting > I don't need to know any > internal properties, just the ability to retrieve an > object and later pass it to a new instance of the applet. > If the new versions still have display settings, that is. Not sure what you mean by 'display settings'. Miguel |
From: Sebastian L. <lisken@Mathematik.uni-bielefeld.de> - 2003-11-05 09:31:17
|
> Using JavaScript: > Almost all attributes can be set through the scripting language. There > currently are no 'getter' methods. > > Using Java: > All attributes are available for getting and setting > Not sure what you mean by 'display settings'. Sorry, that wasn't clear enough. The Jmol applet version I used (0.6.1) had an object called "displaySettings", an object member. This contained all the user-defined settings for display, that was the drawing mode (Wireframe, Quickdraw, Halfshaded - requested and added by me - and Shaded), Label and Bonds display. If you check "http://www.mathematik.uni-bielefeld.de/~CaGe/Images/jmol.jpg" you will understand that these were the display states the user could set by pressing keys, and I wanted to remember that between applet instances. Not manipulate the object in anyway, just get it from one instance and pass it on to the other. Now I would want to remember all the states set by right-clicking. It would be nice if the setter method would take an Object rather than the type used for real, so I wouldn't need to know the exact object type when getting and setting. Sebastian |
From: PHILLIP W B. <pw...@fa...> - 2003-10-29 21:41:18
|
----- Original Message ----- From: "E.L. Willighagen (Egon)" <eg...@sc...> Date: Wednesday, October 29, 2003 1:15 pm > > > Phillip Barak of the University of Wisconsin USA recently sent me > > > a link > > > that shows some excellent web pages with inorganic molecules. You > > > shouldtake a look at them: > > > http://www.soils.wisc.edu/virtual_museum/ > > > > Just to jump in here about our use of pdb files for the minerals > on our > > site: > > > > Using pdb was not our first choice. We would have prefered CIF > format,> files with the barest minimum of spatial information, > since symmetry > > operators allow 'tiling' out in any direction per user > parameters, but that > > was not to be with Chime. > > Jmol v8 has very limited support for PDB files... it reads only > the atomic > coordinates and the unit cell parameters, and symmetry operations > are not yet > supported... I am not sure what you mean with tiling, but what > would the CIF > file that would define the 'tiling' look like? A CIF file for struvite would (minimally) look like: data_struvite _chemical_name_systematic ; magnesium ammonium phosphate hexahydrate ; _cell_length_a 6.955 _cell_length_b 6.142 _cell_length_c 11.218 _cell_angle_alpha 90 _cell_angle_beta 90 _cell_angle_gamma 90 _symmetry_space_group_name_H-M 'P mn2(1)' loop_ _atom_site_label _atom_site_fract_x _atom_site_fract_y _atom_site_fract_z P 0.0000 0.9931 0.0019 O 0.0000 0.9764 0.8649 O 0.0000 0.7618 0.0558 O 0.1823 0.1139 0.0436 Mg 0.0000 0.3766 0.3741 O 0.0000 0.6829 0.2878 H 0.0000 0.7192 0.2017 H 0.0000 0.8174 0.3299 O 0.0000 0.0768 0.4664 H 0.1157 0.0070 0.4999 O 0.2115 0.4852 0.4874 H 0.1989 0.2007 0.1824 H 0.3169 0.1702 0.3020 O 0.2179 0.2618 0.2643 H 0.3200 0.3904 0.5120 H 0.2511 0.6354 0.5027 N 0.0000 0.3657 0.7351 H 0.0000 0.2186 0.7832 H 0.0000 0.3311 0.6473 H 0.1148 0.4557 0.7535 Full description of file format at http://www.iucr.ac.uk/iucr-top/cif/ . Anyway, with the designated spacegroup 'P mn2(1)', the symmetry operations are (a simple case): 1 x,y,z 2 -x+1/2,-y,z+1/2 3 x+1/2,-y,z+1/2 4 -x,y,z On the basis of this information, a viewer should be able to designate a single unit cell or any number of cells to be drawn in the a b c directions, as specified by the user. |
From: E.L. W. (Egon) <eg...@sc...> - 2003-10-30 07:17:45
|
On Wednesday 29 October 2003 22:41, PHILLIP W BARAK wrote: > > Jmol v8 has very limited support for PDB files... it reads only > > the atomic > > coordinates and the unit cell parameters, and symmetry operations > > are not yet > > supported... I am not sure what you mean with tiling, but what > > would the CIF > > file that would define the 'tiling' look like? > > A CIF file for struvite would (minimally) look like: > > data_struvite > _chemical_name_systematic > ; magnesium ammonium phosphate hexahydrate > ; > > _cell_length_a 6.955 > _cell_length_b 6.142 > _cell_length_c 11.218 > _cell_angle_alpha 90 > _cell_angle_beta 90 > _cell_angle_gamma 90 > > _symmetry_space_group_name_H-M 'P mn2(1)' > > loop_ > _atom_site_label > _atom_site_fract_x > _atom_site_fract_y > _atom_site_fract_z <snip> Good, all these but the _symmetry_space_group_name are supported... > Anyway, with the designated spacegroup 'P mn2(1)', the symmetry operations > are (a simple case): 1 x,y,z > 2 -x+1/2,-y,z+1/2 > 3 x+1/2,-y,z+1/2 > 4 -x,y,z We currently have no code that can take either the operations or the spacegroup name (in any convention) and convert this to new atoms... It would be good if someone could work this out (a student project?)... It's fairly easy, but it just takes a lot of time to write it... > On the basis of this information, a viewer should be able to designate a > single unit cell or any number of cells to be drawn in the a b c > directions, as specified by the user. This is possible too. Have a look at the crystal properties window in the application. I don't think setting the crystal box dimensions is setable by script commands yet, but that should be easy... Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html |
From: Geoff R. <Geo...@ye...> - 2003-11-01 16:48:10
|
-----Original Message----- From: PHILLIP W BARAK [mailto:pw...@fa...]=20 Sent: 29 October 2003 17:23 To: Miguel Cc: va...@vr...; Geoff Rowland; jmo...@li...; li...@mo... Subject: Re: [Jmol-users] JmolApplet Wish List[AV Scanned] ----- Original Message ----- From: Miguel <mt...@mt...> Date: Wednesday, October 29, 2003 9:19 am Subject: Re: [Jmol-users] JmolApplet Wish List > > Just discovered, downloaded and spent a few hours playing with > > Jmol-8/JmolApplet-8 and the ?sneak preview? of Jmol-10. ABSOLUTELY > > BRILLIANT! > Glad that you like Jmol >=20 > > The materials I have been working on have been mainly targeted at > > pre-university level (AS and A2 level in UK edu-speak) and involve > > inorganic crystal and metal structures as well as organic molecules > > and biopolymers. All currently use .pdb format. > > Phillip Barak of the University of Wisconsin USA recently sent me=20 > a link > that shows some excellent web pages with inorganic molecules. You=20 > shouldtake a look at them: > http://www.soils.wisc.edu/virtual_museum/ Just to jump in here about our use of pdb files for the minerals on our site: Using pdb was not our first choice. We would have prefered CIF format, files with the barest minimum of spatial information, since symmetry operators allow 'tiling' out in any direction per user parameters, but that was not to be with Chime. (WebLab viewer did a nice job of asking how many cells in each direction and then drawing it up.) Then of course, we found that Rasmol/Chime didn't do a very good job of connecting bonds (allowing Si-Si bonds and Si-Al bonds when it should have been Si-O-Si or Si-O-Al.) And Chime never seemed to get the unit cell drawn correctly. For a while, we used mol format, with bonds specified, but the number of atoms was too limited for any but the smallest mineral models. We moved on to pdb files, with positions and bonds specified, and some of these models require relatively large files. This works well but quite a bit of spacially redundant information is included in the pdb or mol file. --Phil Barak ------------------------------------------------------------------------ --- Yes Phil, that all sounds rather familiar. I obtained most of the 'inorganic' and 'metal' structures I have used from crystallographic data available in .xr format from the UK Chemical Database Service (CDS). Various CDS utilities, together with assorted hacks and edits, were used to fill and expand the unit cells and convert to .pdb format with appropriate CONECT records. These .pdb files do contain much redundant information, but you can specify exactly what the viewer will see. I include the listing of one such .pdb file, for 2x2x2 unit cells of Lithium, below. Apologies, but I don't currently have a public web-site to point you at. One workaround for the display of unit cells in Rasmol/Chime is to stick 'dummy' atoms at the corners of the unit cells and use CONECT records to define the (long) 'bonds' between them. I tend to use Helium atoms for this, as 'real' He atoms are unlikely to be a feature of most structures, and also because the default colouring for such 'unit cells' is a nice light pink :). I usually give these 'chainID' 0 so that the 'unit cell' can be selected with 'select 0' and everything else with 'select not 0'. Also appropriate labels of A, B, C and O can be used to identify the a, b, c vectors and origin of the unit cell (sort-of like WebLab Viewer). I have included COLO (COLOUR or COLOR) records. These are an extension of the PDB introduced by the Raster3D program. They are documented for RasMol 2.6 and 2.7. Combined with 'spacefill user' and 'colour user' they provide a neat way of incorporating non-standard radii (e.g. metallic and ionic radii) and colours in .pdb files. I don't think they are officially documented for Chime, but they do 'sort of' work, presumably through inheritance of RasMol code. In my experience, display is particularly flakey with Chime/Internet Explorer. Finally, I have mainly used ATOM rather than HETATM records for these structures so that I don't keep having to explain what a HETATM is to my students. All-in-all rather messy, but I hope this helps to clarify some of the issues I raised in my original posting. I would be nice if the JmolApplet would render the 'bonds' and 'unitcell' for this type of file. Regards Geoff Rowland HEADER li.pdb TITLE REMARK TRANSLATED FROM CDS REF NO: 38042 REMARK CDS FILES WERE OBTAINED FROM THE UNITED KINGDOM CHEMICAL DATABASE =20 REMARK SERVICE (CDS), FLETCHER, D.A., MCMEEKING, R.F., AND PARKIN, D.J., =20 REMARK CHEM. INF. COMPUT. SCI (1996), 36, 746-749. REMARK CDS, DARESBURY LABORATORY, DARESBURY, WARRINGTON, WA4 4AD. REMARK (http://www.dl.ac.uk) REMARK TRANSLATION USED THE UTILITY PROGRAM FILLXR, FOLLOWED BY XR2PDB =20 REMARK AND ADDITIONAL EDITING =20 REMARK DATA IN COLUMNS 61-66 OF ATOM RECORDS DESCRIBE CHARGE INFORMATION =20 REMARK HETATM RECORDS 36-43 AND THEIR CONECT RECORDS DEFINE THE UNIT CELL REMARK GEOFFREY ROWLAND 02-01-2000 CRYST1 3.491 3.491 3.491 90.00 90.00 90.00 IM-3M ATOM 1 Li MOL 1 -3.491 -3.491 -3.491 1.00 0.00 Li =20 ATOM 2 Li MOL 1 -1.745 -1.745 -1.745 1.00 0.00 Li =20 ATOM 3 Li MOL 1 -3.491 -3.491 0.000 1.00 0.00 Li =20 ATOM 4 Li MOL 1 -1.745 -1.746 1.745 1.00 0.00 Li =20 ATOM 5 Li MOL 1 -3.491 0.000 -3.491 1.00 0.00 Li =20 ATOM 6 Li MOL 1 -1.745 1.746 -1.745 1.00 0.00 Li =20 ATOM 7 Li MOL 1 -3.491 0.000 0.000 1.00 0.00 Li =20 ATOM 8 Li MOL 1 -1.746 1.745 1.745 1.00 0.00 Li =20 ATOM 9 Li MOL 1 0.000 -3.491 -3.491 1.00 0.00 Li =20 ATOM 10 Li MOL 1 1.746 -1.745 -1.745 1.00 0.00 Li =20 ATOM 11 Li MOL 1 0.000 -3.491 0.000 1.00 0.00 Li =20 ATOM 12 Li MOL 1 1.745 -1.746 1.745 1.00 0.00 Li =20 ATOM 13 Li MOL 1 0.000 0.000 -3.491 1.00 0.00 Li =20 ATOM 14 Li MOL 1 1.745 1.746 -1.745 1.00 0.00 Li =20 ATOM 15 Li MOL 1 0.000 0.000 0.000 1.00 0.00 Li =20 ATOM 16 Li MOL 1 1.745 1.745 1.745 1.00 0.00 Li =20 ATOM 17 Li MOL 1 -3.491 -3.491 3.491 1.00 0.00 Li =20 ATOM 18 Li MOL 1 -3.491 3.491 -3.491 1.00 0.00 Li =20 ATOM 19 Li MOL 1 -3.491 3.491 3.491 1.00 0.00 Li =20 ATOM 20 Li MOL 1 3.491 -3.491 -3.491 1.00 0.00 Li =20 ATOM 21 Li MOL 1 3.491 -3.491 3.491 1.00 0.00 Li =20 ATOM 22 Li MOL 1 3.491 3.491 -3.491 1.00 0.00 Li =20 ATOM 23 Li MOL 1 3.491 3.491 3.491 1.00 0.00 Li =20 ATOM 24 Li MOL 1 -3.491 3.491 0.000 1.00 0.00 Li =20 ATOM 25 Li MOL 1 3.491 -3.491 0.000 1.00 0.00 Li =20 ATOM 26 Li MOL 1 3.491 3.491 0.000 1.00 0.00 Li =20 ATOM 27 Li MOL 1 -3.491 -0.000 3.491 1.00 0.00 Li =20 ATOM 28 Li MOL 1 3.491 0.000 -3.491 1.00 0.00 Li =20 ATOM 29 Li MOL 1 3.491 -0.000 3.491 1.00 0.00 Li =20 ATOM 30 Li MOL 1 3.491 0.000 0.000 1.00 0.00 Li =20 ATOM 31 Li MOL 1 0.000 -3.491 3.491 1.00 0.00 Li =20 ATOM 32 Li MOL 1 0.000 3.491 -3.491 1.00 0.00 Li =20 ATOM 33 Li MOL 1 -0.000 3.491 3.491 1.00 0.00 Li =20 ATOM 34 Li MOL 1 -0.000 3.491 0.000 1.00 0.00 Li =20 ATOM 35 Li MOL 1 -0.000 -0.000 3.491 1.00 0.00 Li =20 HETATM 36 He CEL O 0 0.000 0.000 0.000 0.00 0.00 HETATM 37 He CEL C 0 0.000 0.000 3.491 0.00 0.00 HETATM 38 He CEL B 0 0.000 3.491 0.000 0.00 0.00 HETATM 39 He CEL 0 0.000 3.491 3.491 0.00 0.00 HETATM 40 He CEL A 0 3.491 0.000 0.000 0.00 0.00 HETATM 41 He CEL 0 3.491 0.000 3.491 0.00 0.00 HETATM 42 He CEL 0 3.491 3.491 0.000 0.00 0.00 HETATM 43 He CEL 0 3.491 3.491 3.491 0.00 0.00 COLOUR######He###########0#### 0.00 UCEL COLOUR######Li###MOL#####1#### 1.52 METR CONECT 16 35 CONECT 12 35 CONECT 4 35 CONECT 8 35 CONECT 14 34 CONECT 16 34 CONECT 6 34 CONECT 8 34 CONECT 16 33 CONECT 8 33 CONECT 14 32 CONECT 6 32 CONECT 12 31 CONECT 4 31 CONECT 10 30 CONECT 12 30 CONECT 14 30 CONECT 16 30 CONECT 12 29 CONECT 16 29 CONECT 10 28 CONECT 14 28 CONECT 4 27 CONECT 8 27 CONECT 14 26 CONECT 16 26 CONECT 10 25 CONECT 12 25 CONECT 6 24 CONECT 8 24 CONECT 16 23 CONECT 14 22 CONECT 12 21 CONECT 10 20 CONECT 8 19 CONECT 6 18 CONECT 4 17 CONECT 15 16 CONECT 10 15 CONECT 12 15 CONECT 14 15 CONECT 2 15 CONECT 4 15 CONECT 6 15 CONECT 8 15 CONECT 13 14 CONECT 10 13 CONECT 2 13 CONECT 6 13 CONECT 11 12 CONECT 10 11 CONECT 2 11 CONECT 4 11 CONECT 9 10 CONECT 2 9 CONECT 7 8 CONECT 2 7 CONECT 4 7 CONECT 6 7 CONECT 5 6 CONECT 2 5 CONECT 3 4 CONECT 2 3 CONECT 1 2 CONECT 36 37 38 40 CONECT 37 39 41 CONECT 38 39 42 CONECT 39 43 CONECT 40 41 42 CONECT 41 43 CONECT 42 43 END |
From: Miguel <mt...@mt...> - 2003-11-04 13:30:59
|
> Hi again, the recent discussion I joined was about .pdb files and the > "set connect" script command. Miguel said that when there is bond > information in a file, Jmol should stick to it, and I wonder if this > would apply to all formats. Jmol is a visualization program, not a calculations program. If there is connectivity information in a file then Jmol will faithfully render the molecule using that connectivity information. This is independent of file type. (With the caveat that CONECT records are *currently* not used for .pdb files ... this is considered a bug). If the file contains no connectivity information then Jmol applies an algorithm to generate bond links. The current algorithm is quite simple, and uses covalent radii of the two atoms and a 'tolerance' factor. This algorithm will probably change in the future. > I got a colleague who is still working with CaGe to send me two > samples of the CML format that I made our program send to the Jmol > applet. Note the "convention" in the third lines. I wonder what a > current version of the applet would make of them? Unfortunately, I don't know anything about CML. I have been focusing on the scripting and rendering aspects of Jmol. This portion of the code is completely independent from the File IO. One of the other developers will need to take a look at your CML files. > What the display > should be with the "unchemical" file I don't know, I'm afraid - this > is not a question of the "what do you see" style but rather one > for the developers: what would Jmol make of the data in these > files, and would you be willing to make it adhere strictly to the > bonds and atom positions? If the coordinates are in the file *and* the file reader uses them then Jmol should display it exactly as prescribed by the file. I know that if you have a .mol file then the coordinates will be respected. For example, we have a file samples/jmol.mol which is a 'dot-matrix' representation of the letters JMOL using carbon atoms. Looks fine on the screen. Miguel > > Sebastian |
From: Geoff R. <Geo...@ye...> - 2003-11-06 18:07:02
|
>> 2. set connect false/save (and initscript parameter) >> >> For complex structures RasMol and Chime usually ignore CONECT records >> in .pdb files and use their own internal algorithms to determine >> bonds. This means that structures with 'unusual' bond lengths, e.g. >> ionic and metal lattices, may not display correctly even if the bonds >> are >> described by CONECT records. Further explanation and details can be >> obtained from: >> >> http://www.umass.edu/microbio/rasmol/rasbonds.htm >> >> The workaround for this in RasMol 2.6 (not sure about RasMol 2.7) and >> Chime 2 is provided by the set connect false command which forces use >> of the CONECT records. In addition Chime 2 has the set connect save >> command which forces the plugin to show bonds for all CONECT records >> in the .pdb file, while at the same time calculating bonds not >> specified in the CONECT records in the usual manner. Set connect save >> can also be issued in the embed tag which invokes Chime 2 using the >> initscript parameter. Initscript is required to execute the command >> before the molecule is loaded. >> >> It would be nice if the JmolApplet would implement set connect >> false/save with initscript, or some equivalent mechanism, to achieve >> the display of structures with 'unusual' and heterogeneous bond >> lengths. > >Not sure what you mean by 'initscript' ... I have no practical experience >using either Chime or RasMol :-) >Also, I was unable to find any reference in the RasMol doc to 'set >connect' Is this a Chime extension? Or is it just undocumented? Apart from the hyperlink above, 'set connect' and 'initscript' are not well documented. My recollection is that they were developed as fixes to problems raised on the RasMol/Chime mailing lists around the time of the introduction of Chime 2. 'set connect true/false' seems specific to RasMol 2.6 and is not detailed in OpenRasMol 2.7 documentation. 'set connect save' and 'initscript' are Chime 2 specific. Again the definitive (only?) documentation is the above link. initscript =3D "set connect save" is used in the <embed> tag which launches Chime to ensure that the set connect save command is executed before the molecule is loaded. I'm not sure how this would be implemented with the JmolApplet <applet> tag. <embed type=3D"chemical/x-pdb"=20 src=3D"1hho.pdb"=20 height=3D"50%" width=3D"50%"=20 initscript=3D"set connect save"> =20 >Jmol respects atom connectiving in .mol files, but I think it currently >ignores CONECT records in .pdb files ... this needs to be implemented. Aha! If all else fails, I'll convert my .pdb files to .mol format ;) >The RasMol doc talks about using two different algorithms for small vs. >large molecules. Jmol doesn't do this. We have one algorithm that (we >think) is pretty fast. >The rules for bonding are (generally) taken from OpenBabel ... and I >*think* it does a better job with metals than RasMol ... the iron in >hemoglobin hemes is correctly bonded in Jmol but is not bonded at all in >RasMol. >Specific examples of molecules that are not bonding properly would be >helpful. I have already posted an example. The problems are not usually with 'bona fide' molecules but, for example, in displaying closest contacts in body-centred cubic metallic lattices (e.g. lithium) or ionic lattices as 'bonds'.=20 >With that said, clearly we need to implement the 'set connect' behavior >you are describing so that we respect CONECT records when they are present .... >Miguel Regards Geoff Rowland |
From: Sebastian L. <seb...@un...> - 2003-10-29 15:49:33
|
Miguel wrote: [Praise for JMol's bonding algorithm, and a request for molecules not rendered properly] It is a while ago, and I am no longer working on that project, but you might remember me asking something similar in 2000. Out of sentimentality, I'm still lurking. I used an old version of the JMol Applet in a Java application I developed, and tried to make you aware of the fact that sometimes people calculate their own structures, complete with "final" bond and atom position information, and don't want a viewer program trying to be smart and decide where atoms and bonds should be. Did I ever report back when I finished my project? You can see the results at "http://www.mathematik.uni-bielefeld.de/~CaGe/". On the website, we praise JMol because the version we have does exactly what we want, but I don't know if that would still be true in the current version. My point is, I didn't get all I wanted from a standard version of the JMol Applet, so I ended up changing bits of the source code myself, using CML data with a new "Convention" of "MathGraph". I sent messages about my changes, but these seemed to get lost in the activies of JMol development. It would be good if a position such as mine wasn't completely forgotten. From that perspective, Miguel's response is not to the point. My specific requirements were: * Exact representation of input data in terms of atom positions and bonds (Sometimes our bonds even were "impossible" from a chemistry point of view, but I still wanted JMol to faithfully show what it was given to show.) I also needed this to be possible in CML, since that was the only format one could hand to the applet in a parameter. There was no scripting back then. * getter and setter methods for display settings (things like the drawing modes that existed back then) I dreamed of being able to always take the newest version and "plug it in" to my application, and I'd wonder if that could be made possible. Sebastian Lisken |