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
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
Renamed OEShapeDatabase::SetGridSpacing to
Load time has been significantly increased due to the calculation
of color atoms during load time.