[Dock-fans] Single processor optimization

[Francesco Pietra]

HI:
please see below.

--- On Mon, 5/12/08, Scott Brozell <sbrozell at scripps.edu> wrote:

> From: Scott Brozell <sbrozell at scripps.edu>
> Subject: Re: [Dock-fans] Single processor optimization
> To: "Francesco Pietra" <chiendarret at yahoo.com>
> Cc: "dock-fans" <dock-fans at docking.org>
> Date: Monday, May 12, 2008, 2:46 PM
> Hi,
> 
> On Sat, 10 May 2008, Francesco Pietra wrote:
> 
> > --- On Sat, 5/10/08, Sudipto Mukherjee
> <sudmukh at yahoo.com> wrote:
> > 
> > > 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.
> > 
> 
> The story is that grid_score fails because the memory
> needed for the grids
> and the spheres exceeds the available memory.
> continuous score eliminates the grids, but the spheres can
> still
> consume lots of memory.
> I thought this was verified by you and clear.
> And note to those not routinely following your threads that
> your
> docking application is atypical.

I am quite sorry if my answer implied that the reason for failure was not clear to you. Certainly I should have better specified that it is not fully clear to me. I.e., without being able to read a code written in C/C++, I do not understand why the memory is sufficient for continuous and not for grid.
> 
> > > 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)
> > 
> 
> AMD Core Math Library (ACML) is compatible with gfortran,
> Intel, PGI, etc.
> Sometime we shall provide config files for acml.

That would be great, also in view of grid score. Particularly for parallel procedures with many ligands. I could immediately install gfortran fro a deb package, which should also be available to other linuxes.


> But the continuous score code is written very
> inefficiently, and
> there are obvious improvements before considering acml.
> Are you planning significant continuous score calculations
> ?

Absolutely not, unless continuous score may provide docking of large ligands where grid score will always find memory problems. I could use a finer grid to have higher resolution.


Thanks
francesco

> 
> 
> > > ----- Original Message ----
> > > From: Francesco Pietra
> <chiendarret at yahoo.com>
> > > 
> > > 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?
> 
> Please clarify the question.
> Are you suggesting output like
> that from amber score with the -v flag ?
> 
> Scott


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