FastROCS TK 1.8.1

New features

  • This release extends the capabilities of FastROCS TK to allow for 2 types of alternative starting points: user-defined starts and starts at heavy atoms.

    The FastROCS TK algorithm involves optimizing each overlaid query and database molecule by shape. Previously, the optimization had been performed for 4 orientations of each database molecule around its principle axes of inertia.

    User-defined starts allow users to input starting coordinates directly. The database molecule is now translated to each starting position and the 4 inertial poses are optimized.

    Starts at heavy atoms translate each database molecule to each heavy atom plus the center of mass of the query molecule. Again, the 4 inertial poses are optimized at each translation.

    For more information, see OEShapeDatabaseOptions::SetInitialOrientation and OEFastROCSOrientation.

  • A new function, OEFastROCSGetNumDevices, has been added that returns the number of GPUs currently visible. Since no FastROCS TK objects are required, it can be used to probe a system prior to running any queries.

  • A new function, OEIsDatabasePrepared, has been added to check whether a database file has already been run through OEPrepareFastROCSMol. This is useful for ensuring that a database file has been prepared and also saves time by preventing it from being prepared twice. OpenEye recommends preparing all large databases in order to benefit from significantly faster OEShapeDatabase::Open times.

  • The cutoffs in FastROCS TK now support the retrieval of all scores less than or equal to the desired cutoff. See OEShapeDatabaseOptions::SetCutoffLT.

Major bug fixes

  • Customers using Tesla C2050 cards and GTX cards at compute capability 2.x may have experienced some issues with large databases of very small molecules since compute resources were being over-allocated in some scenarios. This issue has been resolved.

Minor bug fixes

  • Warnings had previously been thrown for Tversky scores greater than 1.0 (shape/color). For performance reasons, components of the Tversky/Tanimoto scores can be calculated on either the GPU or CPU. This sometimes results in scores slightly greater than 1.0. Customers should be aware of this possibility when handling scores. A warning is now thrown if a score is greater than 1.2.

  • When opening an OEShapeDatabase object, the presence of invalid molecules now results in a warning rather than error.

  • karma.py can now handle databases with molecules that don’t have titles. A unique title is given to each untitled molecule.