Dear Geoff,I can't give you a precise SVN revision number, however I have attached a version halfway between 2.3.0 and 2.3.1 (mdlformat.cpp.working), which worked in that revision and also works in the current one replacing mdlformat.cpp. The problem is triggered in forcefield.cpp by the
_mol = mol;expression on line 858; after that expression, all formal charges are set to zero, both in _mol and in mol, as evidenced replacing forcefield.cpp with forcefield.cpp.patched, which prints out formal charges before and after the _mol = mol expression. This appears to be a consequence of patom replacing atom in formats/mdlformat.cpp. In fact, reverting that change fixes the issue. I'm sure reverting is not a good solution; it just allowed to pinpoint the source of the problem.
Hope I was clear enough, thanks a lot for your collaboration best regards Paolo On 12/08/2011 08:13 PM, Geoffrey Hutchison wrote:
Hi Paolo, I'm forwarding this to the development list itself -- as a quick summary, 2.3.1 has a small regression to MMFF94 in Cu (and presumably Fe) compounds, where the formal charge is set by a SDF "M CHG" line (as attached). You said this was due to some changes in mdlformat.cpp -- can you give me some revision numbers in SVN? I'm not comfortable reverting mdlformat until we know exactly what caused the regression. There is undoubtedly a cleaner way to solve the problem. I'll also add the CU1PW1 file to the MMFF94 test set to prevent future regressions. Thanks very much, -Geoff On Dec 5, 2011, at 4:47 PM, Paolo Tosco wrote:Dear Geoff, looking at my previous e-mail I can't understand a single word myself :-) so I'll try to be clearer here. I have found a small MMFF94-related regression in OpenBabel 2.3.1, which was not there in the SVN version that I normally use. if you issue $ obenergy -ff MMFF94 CU1PW1.sdf with openbabel 2.3.1 you get A T O M T Y P E S IDX TYPE 1 70 2 31 3 31 4 98 F O R M A L C H A R G E S IDX CHARGE 1 0.000000 2 0.000000 3 0.000000 4 2.000000 P A R T I A L C H A R G E S IDX CHARGE 1 -0.860000 2 0.430000 3 0.430000 4 2.000000 S E T T I N G U P C A L C U L A T I O N S SETTING UP BOND CALCULATIONS... SETTING UP ANGLE& STRETCH-BEND CALCULATIONS... SETTING UP TORSION CALCULATIONS... SETTING UP OOP CALCULATIONS... SETTING UP VAN DER WAALS CALCULATIONS... SETTING UP ELECTROSTATIC CALCULATIONS... E N E R G Y TOTAL BOND STRETCHING ENERGY = 0.23164 kcal/mol TOTAL ANGLE BENDING ENERGY = 0.45413 kcal/mol TOTAL STRETCH BENDING ENERGY = -0.08423 kcal/mol TOTAL TORSIONAL ENERGY = 0.00000 kcal/mol TOTAL OUT-OF-PLANE BENDING ENERGY = 0.00000 kcal/mol TOTAL VAN DER WAALS ENERGY = 6.94628 kcal/mol TOTAL ELECTROSTATIC ENERGY = -61.07838 kcal/mol TOTAL ENERGY = -53.53057 kcal/mol which is wrong. Reverting some of the changes that were made to formats/mdlformat.cpp fixes the issue. The attached patch patch_mdlformat.patch (apply with patch -p0< patch_mdlformat.patch in the openbabel root dir) will apply those reverts. However, probably those patches have been made for some reason, so what fixes my problem might break something else; maybe you have a better fix. mdlformat.cpp currently shipped with OB 2.3.1 triggers a problem in forcefield.cpp, which results in the MMFF atom typing of CU1PW1.sdf to fail. In fact, if you apply the patch patch_forcefield.patch (which just adds a couple of debug printf to forcefield.cpp), you'll see that the original mdlformat.cpp causes a problem when the instruction _mol = mol; between the two added printf's is executed. Afterwards, all atoms have zero formal charge, both those in mol and those in _mol, which seems quite odd to me, since as far as I can understand mol should be unchanged (but I'm not so much a C++ guy). This triggers faulty atom typing on CU1PW1's Cu(I) ion, which is based on the formal charge. My limited C++ skills suggest to me that when mol is copied onto _mol something bad happens. However, I hope I have given you enough information to find a better fix than mine, or accept mine. I hope now things are clearer. Sorry for my previous e-mail, I was REALLY tired and hungry :-P and longing to go to dinner! Best regards, Paolo -- ========================================================== Paolo Tosco, Ph.D. Phone: +39 011 6707680 Department of Drug Science Fax: +39 011 6707687 and Technology Mob: +39 348 5537206 Via Pietro Giuria, 9 10125 Torino, Italy http://open3dalign.org E-mail:paolo.to...@unito.it http://open3dqsar.org ==========================================================
mmff94_bug.tar.bz2
Description: application/bzip
------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
