On 29 August 2012 16:14, Tim Vandermeersch <tim.vandermeer...@gmail.com> wrote: > Hi Benoit, > > On Tue, Aug 28, 2012 at 3:10 PM, benoit-leblanc > <blebl...@materialsdesign.com> wrote: >> Dear All, >> >> Sorry for the mess I've created. In fact I started to work from the >> latest stable version 2.3.1. And then we I got the SVN version in, I >> did not check that there was some update in between for the Conformer >> Search. Shame on me! > > No problem, this can happen. Thanks for the contribution. > >> So I got the latest version before my commit (4914), and >> merged with my changes, and commited (r4992). >> So the virtual issues are gones, and latest classes >> OBMinimizingEnergyConformerScore and OBMinimizingRMSDConformerScore >> are back in business. >> >> Note the in the OBMinimizingEnergyConformerScore, I also added a map >> to bookeep steepest descent + energy result. As a example, in a test >> run I made, it gave 9029 request for 681 actual computations. >> I also noted that >> >> OBMinimizingEnergyConformerScore::Preferred () >> was set to Highest instead of Lowest (since we focus on the lowest >> minimized energy score). >> >> In the OBStericConformerFilter::IsGood method, there was an issue >> with the value of square distance between 2 atoms. It was originally >> set as: >>> double distanceSquared = sqrt (dx*dx + dy*dy + dz*dz); >> And I guess that, in order to save sqrt compuation time, the intention was >> to set it as: >>> double distanceSquared = dx*dx + dy*dy + dz*dz; >> As it is later compared with squard cutoff. >> Moreover the VdW cutoff is applied to all non directly bonded atoms, >> so discarding anything, since e.g. 1-3 carbons in an alcane chain will >> be below the sum of VdW radii. >> For now I fixed it by applying a factor of 0.6, eg.: >>> double vdwCutoff = 0.6 * (etab.GetVdwRad(atom1->GetAtomicNum()) >>> + etab.GetVdwRad(atom2->GetAtomicNum())); >> I guess this could be improved by discarding 1-3 and 1-4 bonded atoms, >> and maybe use a factor of 0.85 or 0.9, as in the end distances below >> the VdW radii will reflect in the energy. >> >> Hope this will help... in the end. > > The GA conformer search was an experiment so it did not receive robust > testing and validation. The tautomer code is also experimental and > perhaps we should have a separate repository or folder for these? > > Tim
I say release early and release often, but make sure you're happy with the API as it can't easily be changed afterwards. Also, documentation that spells out the limitations is a plus; the tautomer code appears to work for a large class of tautomers, so I think it will be useful to people but to avoid bug reports, you should point out that it doesn't work for other tautomers. To be honest, you could make a branch for these (and so forth) but it will never be used, and therefore never tested or improved. - Noel ------------------------------------------------------------------------------ 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-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
