----- Original Message ----- From: Miguel Howard <[EMAIL PROTECTED]> Date: Sunday, January 11, 2004 5:09 pm Subject: Re: ionic radii in Jmol
> > Nor I. I suggested in a previous e-mail that the Jmol > Display/Spacefill/> menu include several options: AnisoTemp, > Covalent, vdWaals, and Ionic > > 'spacefill on' uses vanderwaals > > 'spacefill ionic' was going to be a combination of ionic and covalent > > I wondered whether the name should be changed to something else, > since it > was/is a combination of ionic and covalent. Let's keep it 'ionic'. Now what we _might_ suggest is: if _no_ charge info was supplied, then 'ionic' shouldn't be permissible as a spacefill option at all...absent or grayed out? However, 'spacefill covalent' should be an alternative to vdWaals, available to all. > From my (very naive) > perspective, that made sense ... since I have come to the (perhaps > erroneous) conclusion that a covalent radius is just an ionic > radius with > charge 0. This is roughly right. C-C in diamonds (0 atomic charge) is 1.54lA bond length, or 0.77A radius to each C if close packed. Compare 0.77 w/ the table value of 0.68A covalent radius for C. Bond length for N2 (0 atomic charge) is 1.10A, compare w/ covalent radius of 0.68; O2 (0 atomic charge) is 1.21, also 0.68A covalent radius. (Amazing that C, N, O all have the same covalent radius in the table, but so be it.) I could pick a better set of values and not have to use 0.45A as a fudge factor, but that is work for another day.) Interestingly, the values for elemental (zero atomic charge) Si and Al appear to be the source of the large covalent radii that I mentioned earlier as making a mess of the aluminosilicates, even tho elemental Si and Al don't exist in nature at all (and didn't exist until the dawn of electrochemistry in the early 1800s.) > If this doesn't make sense, then we (the group) will rewind the > discussionand go through it step-by-step until we (the group) are > in general > agreement. I think that we're good on this point. > >> 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.) > > Correct. > > There are two cases where Jmol applies its 'autobond' algorithm > 1. no bond information is specified in the file > independent of the file type > .xyz files never have bond connectivity > 2. in the special case of .pdb files, when there are an > 'insufficient' number of CONECT records > (I am *not* using the same decision criteria as > RasMol/Chime ... that is a separate discussion we can > have if/when we need to) > > So, if there is atomic charge information in the file, what radii > are used > and what is the algorithm? > > I would like to use the same algorithm that I am currently using, > hence my > implementation of: > distance >= 0.4 angstroms > AND > distance <= bondingRadius1 + bondingRadius2 + 0.45 angstroms > > where > bondingRadiusN = > if (charged and ionic entry exists) then > ionic radius entry > else > covalent radius entry > I _like_ this approach! It essentially bonds using which ever scheme the data file supports. > > 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. > > What does Jmol do with these? I'll let you know tomorrow. --Phil ------------------------------------------------------- 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
