<div dir="ltr">John-<br><br>Thank you for the quick and helpful reply. <br><br>I had assumed this was the cause of discrepancies. So in your opinion, results from a screening experiment that was run on a single machine have equal "validity" when compared to the same screening results obtained using two different architectures? <br>
<br>-Marshall<br><br><div class="gmail_quote">On Wed, Jul 16, 2008 at 11:05 AM, John J. Irwin <<a href="mailto:jji@cgl.ucsf.edu">jji@cgl.ucsf.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Marshall<br>
<div><div></div><div class="Wj3C7c"><br>
Marshall Levesque wrote:<br>
> This may be a general question that applies to all of the DOCK<br>
> software suite, or only certain parts:<br>
><br>
> If one were to perform a screening of 100 small compounds (eg from<br>
> ZINC) using DOCK6 (grid energy and/or AMBER score) and the workload<br>
> was split between two different architectures (32-bit/64-bit,<br>
> different compiler versions), are there any issues with using the<br>
> results ranked by energy score? For this described situation, 50<br>
> compounds screened on each machine, same target, same input<br>
> files/parameters.<br>
> I'm asking this because if I run the same set of compounds on two<br>
> different architectures, I get similar results with similar rankings<br>
> and scores, but sometimes there is the occasional swing in score for<br>
> some of the compounds (eg -20 --> -8 for grid energy score). These<br>
> large changes in score are obviously discomforting, but even the small<br>
> changes (-20 --> -19) could cause a significant shift in rankings when<br>
> screen large datasets on the order of 10^5 or 10^6.<br>
><br>
> Those most familiar with the DOCK algorithms might know best. Is the<br>
> difference in score coming from different architectures something to<br>
> do with the calculation of the score? or the orientation/confirmation<br>
> of the compounds by anchor-and-grow?<br>
><br>
> I felt that the limited sampling of the search space results in the<br>
> fact that one can never produce a TRUE score, but more sampling does<br>
> narrow the window of discrepancy in energy score for the same compound<br>
> DOCKed on two different architectures, leading me to believe the<br>
> conformation search is at fault.<br>
><br>
> Any insight into this would be greatly appreciated, thanks!<br>
</div></div>We use a different version of DOCK, but I think the conclusions are<br>
general for the method. It is normal for DOCK to produce very slightly<br>
different results for identical input on different hardware due to<br>
accumulation of small rounding errors on floating point numbers.<br>
Occasionally, the "slight difference" will be at a saddle point during a<br>
step of minimization, resulting in a different local minimum being<br>
found, and thus, potentially dramatically different results. But you<br>
don't have to go to new hardware to see this phenomenon. Just reverse<br>
the order of molecules in the database, so that minimization of a<br>
compound starts with a different random seed.<br>
<br>
The bottom line? Docking can be useful, but has important weaknesses.<br>
Make predictions, test them, and go back afterwards and check the<br>
calculation against the experimental results.<br>
<br>
I hope this helps.<br>
<br>
John<br>
UCSF DOCK Team<br>
_______________________________________________<br>
Dock-fans mailing list<br>
<a href="mailto:Dock-fans@docking.org">Dock-fans@docking.org</a><br>
<a href="http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans" target="_blank">http://blur.compbio.ucsf.edu/mailman/listinfo/dock-fans</a><br>
</blockquote></div><br></div>