I've got a real response coming up shortly (in brief: there might be
bugs, but I'm confident to get UFF and the builder both working for
the PF5, SF6, IF7 series).
I've found this change necessary; either it's an obvious bug fix (we
might get to atoms again after setting UFF_AXIAL_ATOM, and then remove
the tag we just added), or maybe I don't understand what's going on
yet:
Index: src/forcefields/forcefielduff.cpp
===================================================================
--- src/forcefields/forcefielduff.cpp (revision 3640)
+++ src/forcefields/forcefielduff.cpp (working copy)
@@ -729,7 +729,8 @@
// remove any previous designation
atom->DeleteData("UFF_AXIAL_ATOM");
atom->DeleteData("UFF_CENTRAL_ATOM");
-
+ }
+ FOR_ATOMS_OF_MOL(atom, _mol) {
parameterB = GetParameterUFF(atom->GetType(), _ffparams);
if (GetCoordination(&*atom, parameterB->_ipar[0]) == 5) { // we
need to do work for trigonal-bipy!
// First, find the two largest neighbors
I don't want to conflate bugfixes and experimental code too much, obviously.
Regards
Philipp Rumpf
On Tue, Mar 16, 2010 at 6:53 PM, Philipp Rumpf <[email protected]> wrote:
> My initial concern was that Avogadro, in conjuction with OpenBabel,
> did really weird things when attempting to insert a SMILES fragment
> such as "FS(F)(F)(F)(F)F": two of the fluorine atoms are superposed,
> and the UFF optimization performed by default did not succeed in
> splitting them (manual manipulation works, though). Furthermore,
> attempting to insert the SMILES fragment "F[U](F)(F)(F)(F)F" failed
> completely, freezing Avogadro.
>
> My understanding from the source code is this is an OpenBabel issue
> (as well as a missed opportunity for a warning in avogadro): the
> current code results in atoms with atom->GetHyb() == 0, and the
> builder.cpp code fails to deal with these in rather bad ways.
>
> I don't have a fix that's of sufficient quality to go into the code
> yet, but maybe the attached patch is good as a proof of concept, at
> least: it introduces new GetHyb() values of 4 and 5 for atoms such as
> P in PF5 and S in SF6, respectively (I'm not a chemist, but the
> wikipedia article appears to refer to those as sp3d hybridisation and
> sp3d2 hybridisation, respectively). It adds INTHYB patterns for
> recognising 5-valent and 6-valent atoms, as well as forcing
> (incorrectly, for testing) Mo and Cr to always have the new hyb
> values. It adds support for those hyb values in builder.cpp, but only
> in the 0/3-dimensional case.
>
> Does it make sense to have new GetHyb() values, and if so, are 4 and 5
> the right choices? Are there hypervalent molecules with double bonds
> which are not tetrahedral in shape (my understanding is H3PO4 is
> tetrahedral around the P atom)? (Again going on wikipedia, sulfur
> trioxide might be planar, but the UFF optimisation disagrees. This is
> potentially a bug in the UFF implementation).
>
> Is it intentional that GetHyb() returns 0 for unrecognised atoms? If
> so, should builder.cpp deal with this? As a fallback, would random
> atom positioning be better than having several atoms at the same
> coordinates?
>
> In order to see this code in action, it might be helpful to apply this
> patch to git avogadro to remove the UFF optimisation:
>
> diff --git a/libavogadro/src/extensions/insertfragmentextension.cpp
> b/libavogadro/src/extensions/insertfragmentextension.cpp
> index a937194..52741d9 100644
> --- a/libavogadro/src/extensions/insertfragmentextension.cpp
> +++ b/libavogadro/src/extensions/insertfragmentextension.cpp
> @@ -114,14 +114,16 @@ namespace Avogadro {
> {
> builder.Build(obfragment);
>
> - OBForceField* pFF = OBForceField::FindForceField("UFF");
> - if (pFF && pFF->Setup(obfragment)) {
> - pFF->ConjugateGradients(250, 1.0e-4);
> - pFF->UpdateCoordinates(obfragment);
> - }
> + if (0) {
> + OBForceField* pFF = OBForceField::FindForceField("UFF");
> + if (pFF && pFF->Setup(obfragment)) {
> + pFF->ConjugateGradients(250, 1.0e-4);
> + pFF->UpdateCoordinates(obfragment);
> + }
> + }
>
> fragment.setOBMol(&obfragment);
> - fragment.addHydrogens();
> + //fragment.addHydrogens();
> fragment.center();
> }
> }
>
> (end of patch).
>
------------------------------------------------------------------------------
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
