> energy penalties: as the gradients are equal for the two atoms, they > never get split, if the optimisation engine doesn't randomize
Ohh. I feel silly. UFF should now do this. > I'd think the GetHyb() values should probably match the values UFF > uses for coordination, as you propose: 5, 6, 7 for PF5, SF6, IF7 > respectively. Yes, I switched this from your patch to what I committed to SVN. > - S2F10, as built by builder.cpp, post-patch, has the F-S-S-F > dihedral as multiples of 90° rather than 45°, ... > Does anyone use builder.cpp without optimisation?). I think our general policy about OBBuilder is that it should create semi-reasonable coordinates, but expects some level of cleanup with a force field. So I think this case is fine. > uncomfortable with the polynomial in cosT I've chosen for the > pentagonal structure (symmetries of 2, 3, and 4 result in pretty > integer coefficients, while cos(2 * M_PI * 1.0/5.0) doesn't) The Open Babel UFF implementation is different from the publication. I have correct a few obvious bugs, borrowed some fixes from Towhee, and generally changed the angular terms. The published UFF method has minima for angles at 0 and 360, which is obviously a bad idea for geometry optimizations in real life. Since there's no published parameters for 7-coordinate UFF, I think you're fine. :-) > builder: PF5, SF6 work with patch; IF7 doesn't yet work; S2F10 > semi-works (no twist); P2F8 is linear, but no twist; I2F12 doesn't > work. > UFF: PF5, SF6 work; IF7 works with patch; S2F10 works; *P2F8 isn't linear. I wouldn't worry if the builder results aren't perfect textbook, particularly for coordination above 7, or two-center molecules. It's a bit different w.r.t. UFF, since it really is supposed to be a "universal" force field. I also think the XeF4 and XeOF4 are fairly frequently used, depending on the textbook, so it's probably good to get it working in UFF. > Can the same bond be axial wrt its begin atom and > equatorial wrt its end atom? No, that seems highly unlikely. If it's an axial bond, then the end atom is supposed to be big. But then the start atom would need to be small to be equatorial to the end? That sounds contrived. I've applied your last patch as a "draft." It's certainly better than the previous code. If there are some additional special cases which need treatment in UFF, that seems like a good idea. Thanks and best regards, -Geoff ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ OpenBabel-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbabel-devel
