From: Eric Martz <[EMAIL PROTECTED]> Date: Sunday, January 11, 2004 2:10 pm Subject: Re: ionic radii in Jmol
> At 1/11/04, Miguel Howard wrote: > >I have added the table of ionic radii to Jmol. > > - the table is what Phillip sent me: > > Handbook of Chemistry and Physics. 48th Ed, 1967-8, p. F143 > > > I trust you are keeping such literature references and sources in > comments > in the source code, and also in nascent documentation, Miguel. Miguel put the reference into the JavaConstants file. > >The algorithm is as follows: > > - if an atom has no charge, then the covalent radius is used > > (data values from OpenBabel) > > - if an atom has a charge, then it is looked up in the ionic table > > * if it is not found in the ionic table, then the > > covalent radius is returned > > I may have missed (or forgotten) some of this discussion. > > Are you talking about "used" for determining the presence of a > covalent bond, > or "used" in the spacefill rendering? > > If the latter, do you really mean covalent radii? > As stated in > http://www.umass.edu/microbio/rasmol/rasbonds.htm > RasMol uses van der Waals radii or "united atom radii" by default > for > spacefill. > I think Jmol should do the same for backward compatibility. > > I've never been clear about the rationale for using vdW radii in > spacefill > rendering instead of covalent radii. Nor I. I suggested in a previous e-mail that the Jmol Display/Spacefill/ menu include several options: AnisoTemp, Covalent, vdWaals, and Ionic > >I now need the following: > > - small/simple files with charged atoms in the following formats > > * xyz > > * mol > > * pdb > > > Not something I can easily provide. Phil? Will do, early this week if all goes well. > Also, Miguel, I trust you are keeping a list of atomic coordinate > files, > and the files themselves, used for testing -- along with notes > about what > each illustrates. This will probably be very useful over and over. > > > - confirmation that the existing bonding algorithm will give > > acceptable results: > > bondingRadius1 + bondingRadius2 + 0.45 angstroms (tolerance) > > Is "bondingRadiusN" a covalent radius? This is what RasMol/Chime use > (http://www.umass.edu/microbio/rasmol/rasbonds.htm). > But where did you get 0.45 A? R/C use 0.56 A according to the > above doc. Jmol is opening up the opportunity to use ionic radii for bonding calculations whenever atom charge is explicitly specified in the data file, but defaults to covalent radius for bonding in other circumstances for backward compatibility with Chime/RasMol. (I doubt that 0.11 A should change much, but I think that Miguel intends that Jmol thereby maintains compatibility w/ OpenBabel--haven't doublechecked the code.) Chime and RasMol make a mess of aluminosilicates (essentially oxides of silicon and aluminum...the subject matter that Linus Pauling addressed in the 20s and 30s when he was working on the nature of the chemical bond (!). The values of covalent radii for silicon and aluminum are so big that they force Si-Si, Al-Al, and Si-Al bonds in the oxides--nasty. By using standard values of ionic radii (Pauling radii, they're sometimes called), this shouldn't happen. > In fact, as also documented in rasbonds.htm, for all > macromolecules, covalent > bonds are drawn for any two atoms between 0.4-1.9 Angstroms apart. Very clever. C-C is 1.2-1.54A, C-N 1.32-1.36, C-O 1.15-1.43, C-S 1.55-1.81, C-H 1.32-1.36, C-Cl 1.77, O-H 0.96. I missed a few, but you get the idea. > I'd be > somewhat nervous about changing this default only because I have > no > experience with the more sophisticated method -- the simpler > method works > most of the time quite well in my experience. My recollection is > that the > only reason Roger used the simpler method because he was worried > about > performance issues with the computers of the early 1990's. > Probably not an > issue now. Thanks, I'd wondered what the fast and complex algorithms of RasMol and Chime were! --Phil Barak ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
