FastROCS TK 0.4.0

  • An experimental release that includes color support meant for scientific validation with the following implementation caveats:

    • Static color scores are calculated using the alignment generated by a shape driven optimization. Note, a color score is calculated for each of the 4 inertial starting points. Therefore, it is possible for a less favorable shape score to be picked due to a higher tanimoto combo. This is the only part color plays in the optimization.

  • Color is calculated using the grid method in order to be fast enough to keep up with the GPU generated alignments.

  • Color is calculated on the CPU so there is no increased bus overhead for color, but there is a significant increase in CPU usage. Calculating color on the CPU is a strategic move to see if we can get away with calculating color without any significant increase to the overall search time. This release gets part of the way towards that goal: a single core of a Xeon CPU E5520 at 2.27GHz is about 2 times slower at calculating static colors coming out of a single NVidia C2050. Future releases will spread this over multiple CPU cores to better even out the load.

    • The OEShapeScore object has been renamed to OEShapeDatabaseScore to disambiguate it. Renamed the method GetTanimoto to GetShapeTanimoto. Added GetColorTanimoto and GetTanimotoCombo.

    • Add the OEShapeDatabaseType constants namespace to indicate whether a database should store color information as well and whether a query should use color as well.

    • Added OEShapeDatabaseOptions::SetScoreType to be used with the OEShapeDatabaseType constants to indicate what type of search is being done.

    • Renamed OEShapeDatabase::SetGridSpacing to OEShapeDatabase::SetShapeGridSpacing. Added OEShapeDatabase::SetColorGridSpacing.

    • Load time has been significantly increased due to the calculation of color atoms during load time.