On 2013-04-26 11:17, Noel O'Boyle wrote: > It's always good to link changes in the code to specific bugs that > need fixing. It may be useful to see whether you identify such cases > here before you spend time on this. If you decide to go ahead, I would > suggest that you add some test cases to ensure that existing correct > behaviour is retained. Wouldn't you agree it is a bug that an OB atom type has an undefined mapping to other force fields?
> > - Noel > > On 26 April 2013 09:08, David van der Spoel <sp...@xray.bmc.uu.se> wrote: >> On 2013-04-26 07:36, David van der Spoel wrote: >>> On 2013-04-26 05:38, Geoffrey Hutchison wrote: >>>>> I'm looking at types.txt and wondering whether not the internal >>>>> representation of atom types (INT) should be unique? Now there are three >>>>> HO, two H, three C3 etc. >>>> >>>> IIRC, the issue is that some programs have different distinctions. For >>>> example PCModel (PCM) separates between multiple HO types. >>>> >>>> Now that's not saying it's perfect. I think I did a "sort -u" at one >>>> point, because people kept adding to the bottom and there would be >>>> duplicate entries, etc. So if you spot good simplifications, please >>>> suggest them. >>>> >>> I assume it works like this that OB determines the atom type to be HO (H >>> bound to O). Now you can in principle subdivide this into different HO, >>> depending on what the O is bound to. However if you don't use different >>> names for these HO (HO1, HO2 etc.) then the information gets lost, right? >>> >>> I would suggest that >>> 1) no double internal names should be allowed >>> 2) a description of each atom type should be included in the file >> >> How about the following file format: >> # Comment text >> # More Comment text >> # Internal|Description|FF1|FF2|.... >> H|Generic hydrogen|H1|H3|... >> HO|Hydrogen bound to oxygen|HO1|HP|... >> >> where the internal names are unique (and this should be enforced). >> >> I'm happy to implement it, so please let me know if there are grave >> objections. >>> >>> >>>> For example, I don't remember the difference between MM2 "H" type 5 and >>>> type 28. We could certainly separate these. >>>> >>>> -Geoff >>>> >>> >>> >> >> >> -- >> David van der Spoel, Ph.D., Professor of Biology >> Dept. of Cell & Molec. Biol., Uppsala University. >> Box 596, 75124 Uppsala, Sweden. Phone: +46184714205. >> sp...@xray.bmc.uu.se http://folding.bmc.uu.se >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> OpenBabel-Devel mailing list >> OpenBabel-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openbabel-devel -- David van der Spoel, Ph.D., Professor of Biology Dept. of Cell & Molec. Biol., Uppsala University. Box 596, 75124 Uppsala, Sweden. Phone: +46184714205. sp...@xray.bmc.uu.se http://folding.bmc.uu.se ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
