The attached file has a very simple trimethyl [Si]. When printed as a SMILES, and extra H is added to the [Si] atom. This does not appear to happen in the SDF -- printing the SDF doesn't show any extra atoms.
The SDF file does not explicitly state that the Si is a radical, and so OpenBabel assumes you just meant the extra Hydrogen to be there implicitly (this assumption has been annoying me all day). Conversion to many other formats, including printing out the SDF again, will not show implicit Hydrogens. The formula, SMILE, molecular weight, etc, do.
If you use this SDF file it gets it correct (I have added a line specifying that atom 2 is a radical)
OpenBabel06200711312D
4 3 0 0 0 0 0 0 0 0999 V2000
0.0000 -0.6667 0.0000 C 0 0 0 0 0
0.5000 -0.5000 0.0000 Si 0 0 0 0 0
1.0000 -0.6667 0.0000 C 0 0 0 0 0
0.5000 -0.0000 0.0000 C 0 0 0 0 0
1 2 1 0 0 0
2 3 1 0 0 0
2 4 1 0 0 0
M RAD 1 2 2
M END
$$$$
The assumption about implicit hydrogens is rather troublesome.
When an atom has not been explicitly marked as a radical center (which cannot be done in many file formats that OpenBabel reads) and yet has is not valence satisfied, I think there are three possible reasons. (1) The Hydrogen was implicit and should be added automatically. (2) The radical center was 'implicit' and the spin multiplicity of the atom should be changed automatically. (3) It was just a mistake and an error should be raised that the molecule is nonsensical.
OpenBabel always seems to go with option (1), which makes sense for some chemical software, especially that aimed at pharmaceuticals. However, reading in g03 log files for example, especially when the molecule has an overall spin multiplicity specified, option (2) is vastly preferable.
Can we give the user the choice when importing, as to which assumptions to make?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SDF illustrating bug in SMILES writer for [Si]
Logged In: YES
user_id=21420
Originator: NO
This is a strange bug. If I run the SMILES -> SMILES conversion:
echo "CSiC" | tools/babel -ismi -osmi
CSiC
If I add hydrogens:
echo "CSiC" | tools/babel -h -ismi -osmi
[CH3]Si[CH3]
We'll have to carefully check the implicit valence for Si.
Logged In: YES
user_id=1454689
Originator: NO
See http://openbabel.org/wiki/Radicals_and_SMILES_extensions
The SDF file does not explicitly state that the Si is a radical, and so OpenBabel assumes you just meant the extra Hydrogen to be there implicitly (this assumption has been annoying me all day). Conversion to many other formats, including printing out the SDF again, will not show implicit Hydrogens. The formula, SMILE, molecular weight, etc, do.
If you use this SDF file it gets it correct (I have added a line specifying that atom 2 is a radical)
OpenBabel06200711312D
4 3 0 0 0 0 0 0 0 0999 V2000
0.0000 -0.6667 0.0000 C 0 0 0 0 0
0.5000 -0.5000 0.0000 Si 0 0 0 0 0
1.0000 -0.6667 0.0000 C 0 0 0 0 0
0.5000 -0.0000 0.0000 C 0 0 0 0 0
1 2 1 0 0 0
2 3 1 0 0 0
2 4 1 0 0 0
M RAD 1 2 2
M END
$$$$
The assumption about implicit hydrogens is rather troublesome.
When an atom has not been explicitly marked as a radical center (which cannot be done in many file formats that OpenBabel reads) and yet has is not valence satisfied, I think there are three possible reasons. (1) The Hydrogen was implicit and should be added automatically. (2) The radical center was 'implicit' and the spin multiplicity of the atom should be changed automatically. (3) It was just a mistake and an error should be raised that the molecule is nonsensical.
OpenBabel always seems to go with option (1), which makes sense for some chemical software, especially that aimed at pharmaceuticals. However, reading in g03 log files for example, especially when the molecule has an overall spin multiplicity specified, option (2) is vastly preferable.
Can we give the user the choice when importing, as to which assumptions to make?
Logged In: YES
user_id=1189615
Originator: NO
Fixed in v2643 by removing Si IMPVAL entry, so that Si never has implict H.
Logged In: YES
user_id=21420
Originator: NO
I'm re-opening this issue, as discussed on the mailing list. I think this is not a quick fix.