This is a weakness of the Jmol CIF reader that might be addressed
someday. All Jmol is doing right now is
1) looking at the atom_site.type_symbol field.
2) If it is one single character, it is taking that as
atom.elementSymbol.
3) If it is two or more characters, it (now, after my check in)
reduces the second character to lower case and looks up the first two
characters in a table of element symbols.
4) If it doesn't find the symbol, it simply assigns
atom.elementSymbol = "" + ch0;
(the FIRST CHARACTER).
5) Later, as this atom set collection is brought into the model set
(in Frame), atom.elementSymbol is checked again, and this time, if it
is a valid symbol, an atomic number is assigned.
Obviously not perfect. So Jmol is basically jumping straight to your
final option:
- if there are no scattering factors (no coefficients
and no table) then make a guess based on the provided symbol
That's the way it is right now....
Bob
[EMAIL PROTECTED] wrote:
On Tue, April 4, 2006 1:34 pm, Bob Hanson said:
Any symbol may be used as the "atom type" and that symbol (case
included)
is then forever associated with that atom type defined. So I don't think
it is a good idea to assume you can change case to make comparisons or
assignments.
true, but in this case Jmol is comparing just to see if that atom type
symbol matches a known element symbol for the sole purposes of
identifying the element. Certainly it could make a mistake, but that
is the case now in ALL cases. If some author chooses to enter
Copper
in for that field, then it will be read as "cobalt". So that's not an
issue. If the field were being saved for other purposes, I think I'd
agree. The CIF specifications are completely open here, and as in so
many cases, Jmol has to make its best guess as to what the element is.
The atom Label field is what is being kept, not the atom type symbol
field, and that field stays all caps.
What is Jmol doing with the assumed element type? That has a major bearing
on what level of effort needs to be applied.
I use a multi-level approach:
- read the _atom_type.symbol loop
- if the .radius_bond and .radius_contact distances are defined in the
loop then add these to the table for the given .symbol.
- if they aren't defined then use the .scat (factors) to determine the
element type and do a table lookup for default .radius_* values for that
element.
- if there are no scattering factors (no coefficients and no table) then
make a guess based on the provided symbol
[aside: it is actually kinda silly that the cif specs don't provide for an
absolute element identifier in the atom_type family]
Rich
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
