[Dock-fans] Single processor optimization

[Francesco Pietra]

Hi Sudipto:


--- On Sat, 5/10/08, Sudipto Mukherjee <sudmukh at yahoo.com> wrote:

> From: Sudipto Mukherjee <sudmukh at yahoo.com>
> Subject: Re: [Dock-fans] Single processor optimization
> To: chiendarret at yahoo.com, "dock-fans" <dock-fans at docking.org>
> Date: Saturday, May 10, 2008, 2:07 PM
> Hi Francesco,
> 
> I'm not clear why you are using continuous scoring
> while docking, especially with a large protein. An energy
> grid would make the dock run orders of magnitude faster.

Grid flex docking (standard grid size) results immediately in

what () : std::bad alloc

Why the operator () fails is not entirely clear. Scott is the opinion (I believe) that it means running out memory. Why however it is satisfied for continuous score of 29.3% of the available memory? It is now the first time I am insisting with the continuous score, both in the hope to get the complex for this new ligand and anyway to see what happens.

I am not sure - anyway - to have a good balance between sphere select (from a  radius of 24A) and show box (9). If I decrease the number of sphere selected (with radius 23A), while still showbox 9, rigid score runs OK, while flex scoring does not proceed, warning that "could not complete growth, confirm grid box is large enough to contain ligand and try increasing max_orients". Increasing max orients does not solve the problem. Inspection (Chimera) shows that the ligand is entirely within the box (and the box contains all the spheres selected).


> Since you have so much memory, you could easily use a very
> fine grid (0.2A or smaller) if you are concerned about grid
> artifacts. If you wish, you can turn off clustering and ask
> dock to return a large number of poses.

Yah, I was wondering why Dock6 does not afford a variety of conformations. Now it is clear how to do.


> Rescore the poses
> with the continuous scoring function. Even then, you might
> consider to retain only those domains of the protein which
> are close to the binding site. 
> 
> The Redpaper describes using IBM's MASSV libraries for
> optimizing programs on Blue Gene. As far as I know, there
> are no similar libraries we can use with gcc. 

What about AMD or Intel libraries, which are free for noncommercial use? I could compile Dock with icc (with Amber and OpenMPI I use ifort and icc)



>Also, note
> that for a single ligand, you are not getting the benefit
> of of your dual opteron setup. Only one processor core is
> being used for running dock.

I am aware of that. Actually, this NUMA type machine consists of four dual-opteron cpus. The continuous score was launched serial.

Thanks
francesco

 
> The continuous scoring function is mostly used for
> rescoring and not docking as it is quite slow O(mn) for m
> protein and n ligand atoms. The grid scoring however, is
> only O(n) and therefore much faster.
>  
> Regards
> Sudipto Mukherjee
> Graduate Student, Robert C. Rizzo Lab
> Dept. of Applied Math & Statistics, Stony Brook
> University
> 
> ----- Original Message ----
> From: Francesco Pietra <chiendarret at yahoo.com>
> To: dock-fans <dock-fans at docking.org>
> Sent: Saturday, May 10, 2008 12:28:27 PM
> Subject: [Dock-fans] Single processor optimization
> 
> This post is mostly to users of dual-opteron and Linux with
> a final brief question to the developers.
> 
> While performing a continuous flex docking for a large
> ligand on a big protein (NUMA-type machine, opteron 875,
> 2.2MHz, 8GB RAM taken by the process (%MEM 29.3); 1150 min
> to date, as from top; no idea how much time will still be
> required, should hopefully no crash occur) I was reading
> the IBM Redpaper "High throughput computing validation
> for drug discovery using the dock program on a massively
> parallel system" recently referred to in the Dock6
> manual.
> 
> Section "Single processor optimization" describes
> a 43% improvement in speed by using specialized math
> libraries. I am using the standard GNU libraries
> (compilation was with gcc 4.2.3) provided by Debian Linux
> lenny. I wonder whether anyone has found improvements for
> this platform.
> 
> To the developers: since most of the time with this
> CPU-bound code is spent on scoring (Redpaper above), is
> there any plan to implement a monitoring of the progress of
> the scoring, no matter how approximate it might be?
> 
> Thanks
> francesco pietra
> 
> 
> 
> 
> 
> 
>      
> ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now. 
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ