* passes all tests, but is still not 100 percent there
* generalize _centerInVolume for possible future use
* better testing of tetrahedral centers
update tests
* only test ring atoms
* handle 4-coordinate n too
* add a volume check; not all tests pass
* turn off debug printing
* rearrange the order of tests.
if this is not done, we get a seg fault when the github55 test runs.
the whole thing needs to be run under valgrind to track this down
* clear up a memory leak
* a bit more documentation
add a constant for one of the threshold values
* get more permissive on the energy tests.
Only do the extra tetrahedral tests for atoms in at least two rings.
* add a DEBUG_EMBEDDING option to make tracking down failures easier
* enable better debugging when the flag is set
* remove a FIX
* remove some debug printing from the tests
* enforce planarity
* increase the force constant for the impropers
* force constant adapted
* reduced tolerance for planarity and force constants changed for some torsions
* tolerance for planarity increased a bit again
* cerr outputs removed
* planarity tolerance increased
* boost log added in planarity check
o rdkit gains a RDKit::common_properties namespace that contains common string value properties
o Dict.h and below gain getPropIfPresent that attempts to retrieve a property and returns
true/false on success or failure. This is used to optimize access.
o rdkit learns how to pass property keys by reference, not value.
A new namespace has been added to RDKit, common_properties
that contains the std::string values for commonly used
properties. This helps to avoid typos in string values
but also avoids a creation of std::strings from character
values. All accessors (has/get/clear and getPropIfPresent) now pass
the key by reference.
Additionally, getPropIfPresent removes the double lookup
of hasProp/getProp which can be a significant speedup
in the smiles and smarts parsers (10-20%)
which caused issues with negative angles
- made also UFF/AngleConstraint.cpp and MMFF/AngleConstraint.cpp more
robust against angle ranges involving negative values
- added relevant C++ and Python tests
(i.e., equilibrium distances/angles and force constants) from
UFF and MMFF in response to two requests recently appeared
on the RDKit-discuss mailing list:
http://sourceforge.net/p/rdkit/mailman/message/32953737/http://sourceforge.net/p/rdkit/mailman/message/32880156/
- did some clean up on the MMFF code
- NB there are two ABI changes:
1) StretchBendContrib(ForceField *owner,
const unsigned int idx1, const unsigned int idx2, const unsigned int idx3,
const MMFFStbn *mmffStbnParams, const MMFFAngle *mmffAngleParams,
const MMFFBond *mmffBondParams1, const MMFFBond *mmffBondParams2);
previously was:
StretchBendContrib(ForceField *owner,
const unsigned int idx1, const unsigned int idx2, const unsigned int idx3,
const std::pair<bool, const MMFFStbn *> mmffStbnParams,
const MMFFAngle *mmffAngleParams, const MMFFBond *mmffBondParams1,
const MMFFBond *mmffBondParams2);
2) std::pair<double, double> calcStbnForceConstants(const MMFFStbn *mmffStbnParams);
previously was:
std::pair<double, double> calcStbnForceConstants
(const std::pair<bool, const MMFFStbn *> mmffStbnParams);
The two changes are NOT mandatory - however, both the StretchBendContrib constructor
and calcStbnForceConstants(), though public, are basically "internal" method that
most likely no-one has ever invoked. Given that the current API is MUCH better
and cleaner, I would really advise for the new version.
to segfault when a system not listed in the MMFFBndk
table was found. THe Herschbach-Laurie fallback according
to MMFF.V was implemented and a relevant test was added
in testMMFFHelpers.cpp
- fixed a bug in Code/GraphMol/ForceFieldHelpers/MMFF/AtomTyper.cpp
which caused misassignment of atom types in CYGUAN01 upon shuffling
the order of atoms in the validation SDF files
- added checks for acos and asin function parameters to be within
a (-1, 1) range
Code/ForceField/MMFF/Params.h, Code/ForceField/UFF/Params.h,
Code/GraphMol/ForceFieldHelpers/MMFF/AtomTyper.cpp
and Code/GraphMol/ForceFieldHelpers/MMFF/AtomTyper.h (I realized
their uselessness thanks to a warning issued by Intel C++ compiler)
- refactored O3A code
- added the possibility to set weighted constraints on selected
atom pairs
- added an option to carry out local-only optimization
whose absence might cause intermittent problem in parsing the
logs on Windows due to tellg/seekg not correctly handling CR/LF
- Fixed the code for assigning the HOCN MMFF94 atom type
(thanks to Toby Wright for reporting this)
- Added a missing copyright notice in testMMFFForceField.h
This covers at least the specific instances from the bug report.
Still need to figure out a general way to identify these automatically
to make sure all are fixed.
removed when the heavy atom they are connected to is not
in its default valence state, while it has one of the
acceptable valence states (otherwise it still has to be
removed for sanitization purposes)
- updated the MMFF validation suite SMILES accordingly
Code/ForceField/MMFF/testMMFFForceField.h
- re-prepared the SDF files from their MOL2 counterparts present in the
original MMFF validation suites. For this purpose a C++ program was
written which only uses information in MOL2 files and in .fc files
provided by Halgren. The C++ program does not depend on RDKit.
- re-prepared the SMILES files from their SDF counterparts using
a Python script which calls MolToSmiles()
- found an issue which affects 2 files in the test suite, namely
ERULE_05 and PO02A (only the hypervalent notation). The issue is
connected with removal of hydrogens bonded to phosphorous and
appears to be fixed by the modifications in Code/GraphMol/AddHs.cpp
and Code/GraphMol/SmilesParse/SmilesWrite.cpp. This issue is
independent of the changes ini the SDF files; indeed, it has
always been present, and had been previously addressed by
manual correction of the two SMILES strings
data races in the multithreaded test
- Removed a spurious #include in Code/ForceField/Wrap/ForceField.cpp
- Restored caching in Code/GraphMol/Descriptors/Crippen.cpp
