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.