Here's another problem in 2.3.x that's not in 2.2.x. I realize these are
bogus molecules, but it illustrates a serious problem.
$ echo "[Fe+2][Fe-2].[Fe+2].[Fe-2]" | babel -i smi -o can
[Fe-2][Fe+2].[Fe-2].[Fe+2]
Everything looks good -- charges are maintained. Now go through the SDF
format:
$ echo "[Fe+2][Fe-2].[Fe+2].[Fe-2]" | babel -i smi -o sdf | babel -i sdf
-o can
[Fe+2][Fe].[Fe].[Fe]
Not so good -- charges are dropped. Where is the problem? It turns out the
SDF is correct:
$ echo "[Fe+2][Fe-2].[Fe+2].[Fe-2]" | babel -i smi -o sdf
OpenBabel05161216052D
4 1 0 0 0 0 0 0 0 0999 V2000
0.0000 0.0000 0.0000 Fe 0 2 0 0 0 0 0 0 0 0 0 0
0.0000 0.0000 0.0000 Fe 0 6 0 0 0 0 0 0 0 0 0 0
0.0000 0.0000 0.0000 Fe 0 2 0 0 0 15 0 0 0 0 0 0
0.0000 0.0000 0.0000 Fe 0 6 0 0 0 15 0 0 0 0 0 0
1 2 1 0 0 0 0
M CHG 4 1 2 2 -2 3 2 4 -2
M END
$$$$
The charges are all properly marked in the atom block and in the M CHG
line. And the "15" in atoms 3 and 4 means "zero valence" which is right.
Yet the SMILES is wrong.
It turns out this same thing happens if you use atom->SetFormalCharge().
It sometimes works and sometimes doesn't.
Note that it works correctly in OpenBabel 2.2.x:
$ echo "[Fe+2][Fe-2].[Fe+2].[Fe-2]" | babel -i smi -o sdf | babel -i sdf
-o can
[Fe-2].[Fe-2][Fe+2].[Fe+2]
Anyone have any idea what changed, either in the OpenBabel internals or the
SMILES generator, that would affect the way charges are interpreted?
Craig
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenBabel-discuss mailing list
OpenBabel-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
