Thank you Egon and Miguel for your answers. > Right... one neighbor too much. Fixed by Miguel in the reaction/ branch: > > http://cdk.svn.sourceforge.net/viewvc/*checkout*/cdk/branches/miguelrojasch/reaction/src/main/org/openscience/cdk/config/data/cdk_atomtypes.xml?revision=HEAD&content-type=text%2Fxml
I see the new list does now also include a boolean "unpaired electron". Very nice. Also I didn't know of "ISingleElectron". > planar3 is actually a sp2 hybridization too; the difference is where > the LP or unpaired electron is located. > For planar3, pz is filled with the LP or the unpaired electron, while > for sp2 it is filled with electrons involved in a pi bond. I see the point. > It would be better to have full markup of which orbitals are involved > in the atom type, and which are filled with what, but the CDK does > currently not support that, though I'm silently working on a > rewrite... That sounds interesting indeed... >> Some atom types such as "O.sp3" and "O.planar3" are configured the same >> (except for the hydridization type). Are they treated differently within >> CDK? > > Yes. Note that atom types can even be differentiated beyond the atom > type... e.g. there is a N.amide atom type, in addition to the > N.planar3. The reason for this flexibility is to be compatible with > other atom typing schemes, such as used in force fields. The design > goal is to have simple one-to-one translation tables. I had a look at the code of CDKAtomTypeMatcher.java and realized that the atom type detection for "O.planar3" actually takes the atom's neighbours into account. So there's a lot more to it than just the atom types list. @Miguel: > Right. The .planar3 and .sp2 represents the same geometry (planar )but > for different atomtypes. Thus, O.planar3 is the ether functional group > and O.sp2 represents the carbonyl group. Same geometry but different > atomtype. Isn't the aliphatic ether group O.sp3 and only the aromatic ether group is O.planar3? General note: The new atom typing does really make a good impression on me. When I tried to fix some SmilesParser bugs in autumn last year I quickly realized that many of them were caused by DeduceBondSystemTool which in turn relied on atom typing, hydrogen counts, and aromaticity detection. Hopefully those DeduceBondSystemTool bugs can be fixed now with the latest progress on atom typing :) Andreas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Cdk-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cdk-user
