>> Thanks for pointing that out. This means in practice that OB can not >> distinguish between all those atomtypes that are used in random >> packages, right? ... > we are busy developing a new force field, and would like to use the OB > types as the basis, to be translated to new force field atom types, > which would need to be a subset of these types.
It's up to you, but my feeling is that it's better for external users to set up a list of separate SMARTS for your atom types, much like the current force fields. This has the benefit that others can port the atom typing rules to other packages. I'd be happy to help you set up the SMARTS given a set of initial typing rules. See gaff.prm for an example. Also, many people can read, understand, and tweak SMARTS. (MMFF94 doesn't currently use SMARTS in our implementation, but I think ChemKit and possible Jmol developed these and I've considered porting our code to use SMARTs to be consistent with the other forcefields in OB.) > On a side note, it seems that a number of Nitrogen atom types have > atomnumber 6 (or maybe Rar and R are carbons anyway?) > Rar 6 0 62 1 C C 3 C 2 R.ar 33 C C 2 1 C.0 26 1 > R 6 0 62 1 C C 3 C 2 R. 33 C C 2 1 C.0 26 1 > Nr 6 0 62 8 C C 3 C 2 Nr. 33 C C 2 1 C.0 26 8 Hm. I've always taken "R" as a carbon, but Nr looks funny. -Geoff ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
