From: Patrick J. C. <car...@sa...> - 2005-03-10 14:29:03
|
When reading a shelxl .res file, Jmol 10.00 does not draw bonds to transition metals. Where are the covalent radii stored? I'd like to re-build Jmol with correct metal radii. Patrick J. Carroll, Ph.D. Director, X-ray Facility Department of Chemistry University of Pennsylvania Philadelphia, PA e-mail: car...@sa... phone: (215)-898-3505 |
From: Patrick J. C. <car...@sa...> - 2005-03-11 01:53:11
|
SHELXL .res files do not have any charge info (as several respondents have remarked). Generally, to draw bonds to metals, the covalent radius is used and usually there is a rather large tolerance to what is considered bonding distance (maybe 20-25% of the sum of the covalent radii). For the most part, this enables the correct drawing of the great majority of bonds (and this also takes into account differences in covalent radii due to charge). But it appears that Jmol does not use the covalent radii to decide bonding distances - the covalent radii stored in Jmolconstants.java are reasonable (a no. of them are even overestimated). For example, I have a Europium compound with Eu-O bond distances of 2.2 - 2.3 Angstroms; the covalent radii for Eu and O in Jmolconstants are 1.99 + 0.68 = 2.67 ! There must be something else going on! Pat Carroll |
From: Bob H. <ha...@st...> - 2005-03-11 02:23:12
|
Pat, Well, that is curious. My test shows up a Eu-O bond at anything less than about 3.1 Angstroms. So actually, Jmol is being pretty generous there as well. I don't think it's possible that you could have a Eu-O bond that is not showing up if it is only 2.3 Angstroms apart. Something else must be going on with this file. Mine was an XYZ file, but that shouldn't have anything to do with it. Could you forward that .res file to me so I can take a look at it? (off-list, please). Bob Hanson Patrick J. Carroll wrote: > SHELXL .res files do not have any charge info (as several respondents > have remarked). Generally, to draw bonds to metals, the covalent radius > is used and usually there is a rather large tolerance to what is > considered bonding distance (maybe 20-25% of the sum of the covalent > radii). For the most part, this enables the correct drawing of the great > majority of bonds (and this also takes into account differences in > covalent radii due to charge). > > But it appears that Jmol does not use the covalent radii to decide > bonding distances - the covalent radii stored in Jmolconstants.java are > reasonable (a no. of them are even overestimated). For example, I have a > Europium compound with Eu-O bond distances of 2.2 - 2.3 Angstroms; the > covalent radii for Eu and O in Jmolconstants are 1.99 + 0.68 = 2.67 ! > There must be something else going on! > > > Pat Carroll > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr |
From: Bob H. <ha...@st...> - 2005-03-11 02:40:54
|
Ah: Also added in there is a bondTolerance of 0.45 Angstroms. In modelmanager.java we have: public float bondTolerance = 0.45f; and in datamodel/frame.java: float maxAcceptable = bondingRadiusA + bondingRadiusB + bondTolerance; So 2.67+0.45 = 3.12 right on the cutoff I was seeing. I think it's working properly. Bob Bob Hanson wrote: > Pat, > > Well, that is curious. My test shows up a Eu-O bond at anything less > than about 3.1 Angstroms. So actually, Jmol is being pretty generous > there as well. I don't think it's possible that you could have a Eu-O > bond that is not showing up if it is only 2.3 Angstroms apart. Something > else must be going on with this file. Mine was an XYZ file, but that > shouldn't have anything to do with it. > > > Could you forward that .res file to me so I can take a look at it? > (off-list, please). > > Bob Hanson > > > > Patrick J. Carroll wrote: > >> SHELXL .res files do not have any charge info (as several respondents >> have remarked). Generally, to draw bonds to metals, the covalent >> radius is used and usually there is a rather large tolerance to what >> is considered bonding distance (maybe 20-25% of the sum of the >> covalent radii). For the most part, this enables the correct drawing >> of the great majority of bonds (and this also takes into account >> differences in covalent radii due to charge). >> >> But it appears that Jmol does not use the covalent radii to decide >> bonding distances - the covalent radii stored in Jmolconstants.java >> are reasonable (a no. of them are even overestimated). For example, I >> have a Europium compound with Eu-O bond distances of 2.2 - 2.3 >> Angstroms; the covalent radii for Eu and O in Jmolconstants are 1.99 + >> 0.68 = 2.67 ! There must be something else going on! >> >> >> Pat Carroll >> >> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Jmol-users mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr |
From: Bob H. <ha...@st...> - 2005-03-11 18:06:44
|
The problem is in the RES file decoder not recognizing "EU1" as europium. If I replace "EU1" in that file with "Eu" the bonds are there. ("EU" does not work, either.) The same problem is with "LI" or "LI1" not being recognized as Li. In fact, with this reader, no two-character caps element names are being read properly. I think it's in ShelxReader.java. Who will volunteer to look into this? Egon? What is needed here is the sort of parsing that the CIF reader or PDB reader uses to get atom.elementSymbol probably using Atom.isValidElementSymbolNoCaseSecondCharacter() But Pat is right that there is also another issue. The Li-O distances here are about 1.9 A. This compares well with others I know (listed in pm): http://www.stolaf.edu/depts/chemistry/mo/struc/explore.htm?bond=Li-O In this data set, the Li-O bond ranges in length between 188.3 and 249.4 pm. Li-O 188 tetrahedral (C4H8O)4Li+ tetrakis(tetrahydrofuran)lithium cation Li-O 196 square pyramidal (C18H32O4)Li(NCS) Li-O 213 square pyramidal (C8H16O4)LiCl (12- crown- 4)- chloro- lithium Li-O 222 square antiprism (C8H16O4)2Li+ bis(12- crown- 4)- lithium cation Since the O covalent radius is set at 68 pm, for these to show, with the 45 pm tolerance, we would need a radius of... 113 + about 110 pm for Li. I suggest the lithium covalent radius get changed to what Pat suggests, 120 pm, i.e. 1200 mar, with a comment added that it was for these purposes. Bob Hanson Pat Carroll wrote: Bob, I've attached a PDB file and a RES file for that Eu compound - the PDB file will have all the bonds drawn in explicitly. Jmol also has trouble with the Li atom in this molecule, but that's understandable - the covalent radius for Li in Javaconstants.java (0.68 A) is too small, it should be something like 1.2. BTW, Jmol10pre8 draws the bonds to Eu correctly!! Thanks, Pat -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: <rg...@el...> - 2005-03-11 19:20:09
|
On Fri, March 11, 2005 1:06 pm, Bob Hanson said: > The problem is in the RES file decoder not recognizing "EU1" as europium. The shelx atom name is an arbitrary string that matches a corresponding string in its scattering-factor definitions. To be perfectly general the reader would need to parse the SFAC instruction and match atom-type (given by the table number in the ATOM info) to the element designator label in the SFAC instruction and, potentially, decode the general SFAC instruction to determine the closest neutral atom-type. > > > But Pat is right that there is also another issue. The Li-O distances here > are > about 1.9 A. This compares well with others I know (listed in pm): > > http://www.stolaf.edu/depts/chemistry/mo/struc/explore.htm?bond=Li-O > > In this data set, the Li-O bond ranges in length between 188.3 and 249.4 > pm. > > Li-O 188 tetrahedral (C4H8O)4Li+ tetrakis(tetrahydrofuran)lithium cation > Li-O 196 square pyramidal (C18H32O4)Li(NCS) > Li-O 213 square pyramidal (C8H16O4)LiCl (12- crown- 4)- chloro- lithium > Li-O 222 square antiprism (C8H16O4)2Li+ bis(12- crown- 4)- lithium cation > A histogram of all Li-O distances in the Cambridge Database shows an interesting bell curve with a max. at ~1.9 and a long tail up to 2.6'ish and a shorter tail to 1.7. The real question comes down to are there Li-O distances less than 2.6 that *aren't* bonds? Rich |
From: Bob H. <ha...@st...> - 2005-03-11 20:26:59
|
rg...@el... wrote: > On Fri, March 11, 2005 1:06 pm, Bob Hanson said: > >>The problem is in the RES file decoder not recognizing "EU1" as europium. > > > The shelx atom name is an arbitrary string that matches a corresponding > string in its scattering-factor definitions. To be perfectly general the > reader would need to parse the SFAC instruction and match atom-type (given > by the table number in the ATOM info) to the element designator label in > the SFAC instruction and, potentially, decode the general SFAC instruction > to determine the closest neutral atom-type. > Perfect. Yes, this should be implemented. Very easy: SFAC C H O LI EU 1 2 3 4 5 sets up SfacEntry[] array EU1 5 0.815442 0.194311 0.684236 11.00000 0.02058 ... O1 3 0.893443 0.086963 0.776878 11.00000 0.02120 ... O2 3 0.935827 0.187239 0.650785 11.00000 0.02032 ... EU1 is fifth entry, so Eu; O1 is 3rd entry, so O; atom.elementSymbol=SfacEntry[i] Excellent. Egon? Bob Hanson > >> >>But Pat is right that there is also another issue. The Li-O distances here >>are >>about 1.9 A. This compares well with others I know (listed in pm): >> >>http://www.stolaf.edu/depts/chemistry/mo/struc/explore.htm?bond=Li-O >> >>In this data set, the Li-O bond ranges in length between 188.3 and 249.4 >>pm. >> >>Li-O 188 tetrahedral (C4H8O)4Li+ tetrakis(tetrahydrofuran)lithium cation >>Li-O 196 square pyramidal (C18H32O4)Li(NCS) >>Li-O 213 square pyramidal (C8H16O4)LiCl (12- crown- 4)- chloro- lithium >>Li-O 222 square antiprism (C8H16O4)2Li+ bis(12- crown- 4)- lithium cation >> > > A histogram of all Li-O distances in the Cambridge Database shows an > interesting bell curve with a max. at ~1.9 and a long tail up to 2.6'ish > and a shorter tail to 1.7. The real question comes down to are there Li-O > distances less than 2.6 that *aren't* bonds? > > Rich > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2005-03-11 02:34:15
|
> SHELXL .res files do not have any charge info (as several respondents h= ave > remarked). Generally, to draw bonds to metals, the covalent radius is u= sed > and usually there is a rather large tolerance to what is considered > bonding > distance (maybe 20-25% of the sum of the covalent radii). For the most > part, this enables the correct drawing of the great majority of bonds (= and > this also takes into account differences in covalent radii due to charg= e). OK > But it appears that Jmol does not use the covalent radii to decide bond= ing > distances - the covalent radii stored in Jmolconstants.java are reasona= ble > (a no. of them are even overestimated). Jmol does use the covalent radii to determine bonding when no charge data= is present. It uses the ionic bonding radii when charge data is present. For each atom it gets the bondingRadius (based upon the rules above) if ((distance < (bondingRadiusA + bondingRadiusB + 0.45) && (distance > 0.4)) form a bond > For example, I have a Europium > compound with Eu-O bond distances of 2.2 - 2.3 Angstroms; the covalent > radii for Eu and O in Jmolconstants are 1.99 + 0.68 =3D 2.67 =21 There = must be > something else going on=21 Don't know. Send me a small file offlist. Miguel |
From: Rich <rg...@el...> - 2005-03-12 11:44:03
|
On 3/11/05 15:26, Bob Hanson wrote: >rg...@el... wrote: > > > >Perfect. Yes, this should be implemented. Very easy: > >SFAC C H O LI EU > 1 2 3 4 5 > > with the one caveat that not all elements are encoded in shelx via that form of the SFAC. There is also the general form SFAC [with scattering factor curve coefficients] for this form the zeroth element of the equation would need to be calculated so the Z value of the element could be determined (and hence the element identity derived). Rich |
From: Miguel <mi...@jm...> - 2005-03-12 15:38:11
|
>>Perfect. Yes, this should be implemented. Very easy: >> >>SFAC C H O LI EU >> 1 2 3 4 5 >> >> > with the one caveat that not all elements are encoded in shelx via that= > form of the SFAC. There is also the general form > > SFAC =5Bwith scattering factor curve coefficients=5D > > for this form the zeroth element of the equation would need to be > calculated so the Z value of the element could be determined (and hence= > the element identity derived). Rich, Can you send me a file that has this *issue*? I could use another 2 or 3 shelx files anyway ... we only have 1 or 2 in the source code repository for testing. Miguel |
From: Bob H. <ha...@st...> - 2005-03-10 15:01:08
|
Patrick J. Carroll wrote: > When reading a shelxl .res file, Jmol 10.00 does not draw bonds to > transition metals. Where are the covalent radii stored? I'd like to > re-build Jmol with correct metal radii. These are in jmolconstants.java Q1. I think you mean "not draw bonds to some transition metals in some cases." Right? Q2. Will your radii depend upon oxidation state? The reason I ask is that it isn't quite as simple as changing the radius. My personal experience is that no program can always get all the bonds perfectly. But expert help with these numbers would be appreciated, I'm sure, if you have better information than what is there already, go for it. Some exerpts: /** * Default table of covalent Radii. * stored as a short mar ... Milli Angstrom Radius * Used for bonding atoms when the client does not supply bonds. * Values taken from OpenBabel. * @see <a href='http://openbabel.sourceforge.net'>openbabel.sourceforge.net</a> */ public final static short[] covalentMars = { 2000, // 0 Xx big enough to bring attention to itself 230, // 1 H 930, // 2 He 680, // 3 Li 350, // 4 Be 830, // 5 B ... 1470, // 22 Ti ... 1350, // 25 Mn ... }; /**************************************************************** * ionic radii are looked up using a pair of parallel arrays * the ionicLookupTable contains both the elementNumber * and the ionization value, represented as follows: * (elementNumber << 4) + (ionizationValue + 4) * if you don't understand this representation, don't worry about * the binary shifting and stuff. It is just a sorted list * of keys * * the values are stored in the ionicMars table * these two arrays are parallel * * This data is from * Handbook of Chemistry and Physics. 48th Ed, 1967-8, p. F143 * (scanned for Jmol by Phillip Barak, Jan 2004) ****************************************************************/ public final static int FORMAL_CHARGE_MIN = -4; public final static int FORMAL_CHARGE_MAX = 7; public final static short[] ionicLookupTable = { (1 << 4) + (-1 + 4), // 1,-1,1.54,"H" (3 << 4) + (1 + 4), // 3,1,0.68,"Li" (4 << 4) + (1 + 4), // 4,1,0.44,"Be" (4 << 4) + (2 + 4), // 4,2,0.35,"Be" (5 << 4) + (1 + 4), // 5,1,0.35,"B" (5 << 4) + (3 + 4), // 5,3,0.23,"B" ... (22 << 4) + (1 + 4), // 22,1,0.96,"Ti" (22 << 4) + (2 + 4), // 22,2,0.94,"Ti" (22 << 4) + (3 + 4), // 22,3,0.76,"Ti" (22 << 4) + (4 + 4), // 22,4,0.68,"Ti" ... (25 << 4) + (2 + 4), // 25,2,0.8,"Mn" (25 << 4) + (3 + 4), // 25,3,0.66,"Mn" (25 << 4) + (4 + 4), // 25,4,0.6,"Mn" (25 << 4) + (7 + 4), // 25,7,0.46,"Mn" ... }; public final static short[] ionicMars = { 1540, // "H",1,-1,1.54,1540 680, // "Li",3,1,0.68,680 440, // "Be",4,1,0.44,440 350, // "Be",4,2,0.35,350 350, // "B",5,1,0.35,350 230, // "B",5,3,0.23,230 960, // "Ti",22,1,0.96,960 940, // "Ti",22,2,0.94,940 760, // "Ti",22,3,0.76,760 680, // "Ti",22,4,0.68,680 ... 800, // "Mn",25,2,0.8,800 660, // "Mn",25,3,0.66,660 600, // "Mn",25,4,0.6,600 460, // "Mn",25,7,0.46,460 ... }; public static short getBondingMar(int elementNumber, int charge) // ionicLookupTable is a sorted table of ionic keys // lookup doing a binary search // when found, return the corresponding value in ionicMars // if not found, just return covalent radius Q3. So a question I would ask is, does the .res format specify oxidation state? If not, you won't be able to access these better values. Bob Hanson > > > Patrick J. Carroll, Ph.D. > > Director, X-ray Facility > Department of Chemistry > University of Pennsylvania > Philadelphia, PA > > e-mail: car...@sa... > phone: (215)-898-3505 > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr |
From: Miguel <mi...@jm...> - 2005-03-10 16:07:07
|
>> When reading a shelxl .res file, Jmol 10.00 does not draw bonds to >> transition metals. Where are the covalent radii stored? I'd like to >> re-build Jmol with correct metal radii. =5Bsnip=5D > Q3. So a question I would ask is, does the .res format specify oxidatio= n > state? > If not, you won't be able to access these better values. I strongly suspect that this is the problem ** 2 minutes later** I just took a look at the ShelxReader ... there is no support for charges= . So the ionic radii table is never going to be used. I also looked at a shelx file ... I could not find anything that looks like formalCharge data in the atom records. Q: Does anyone know anything about shelx files? Do they contain charge da= ta? Q: If there is no charge data in the files, is there anything that we can= do? Bob, you used the term 'oxidation state'. Internally I use the term 'formalCharge' ... I may have asked this question before, but ... Q: In 25 words or less, what is the difference between 'oxidation state' and 'formalCharge'? Miguel |
From: Bob H. <ha...@st...> - 2005-03-10 17:07:21
|
> > Bob, you used the term 'oxidation state'. Internally I use the term > 'formalCharge' ... I may have asked this question before, but ... > > Q: In 25 words or less, what is the difference between 'oxidation state' > and 'formalCharge'? > Oxidation state (oxidation number) supposedly doesn't depend upon your bonding model. (You should be able to discern it with spectroscopic or chemical techniques.) Formal charge is based on a specific bonding model, usually Lewis. Bonding models are subjective. In H2SO4, we would all agree that the S is in the +6 oxidation state. But some people would assign +2 and others +0 to the formal charge, depending upon what model they use for the SO connections. Is the short S-O bond in H2SO4 due to S=O or S(+)-O(-)? Covalent or ionic? People disagree. The difference affects the formal charge (2+ if you like the ionic idea; 0 if you like S=O double bonds), not the oxidation state (+6 in either case). The oxidation state of Mn in KMnO4 is 7+. I don't think anyone believes that it has a formal charge of 7+. Maybe 1+ or 0. N in NH4(+) has a 1+ formal charge. But it's oxidation state is the same as in NH3, which is 3-. SHELX is a crystallography program. If focuses on the nuclei, not the bonding. You take the points and assign bonding as a later interpretation of the data. I'm not surprised that the "raw" data doesn't specify bonding, oxidation state, or formal charge. Bob -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: <rg...@el...> - 2005-03-10 17:35:25
|
On Thu, March 10, 2005 11:07 am, Miguel said: > I just took a look at the ShelxReader ... there is no support for charges. > So the ionic radii table is never going to be used. > > I also looked at a shelx file ... I could not find anything that looks > like formalCharge data in the atom records. > > Q: Does anyone know anything about shelx files? Do they contain charge > data? > > Q: If there is no charge data in the files, is there anything that we can > do? As Bob mentioned SHELX .res files contain the (crystallographically refined) positions of the nuclei of the structure model. There is nothing about bonding, charge or any other atomic property (other than atomic type). All the other information that one might like to have available for Jmol (explicit bonds, charges, etc.) would need to be provided in some other format (CIF probbably) by the chemist/crystallographer. Rich |