[Dock-fans] Generating grid for big molecules

[Francesco Pietra]

In a reply to myself (please see below), while I still hope to get help.

On Wed, Sep 24, 2008 at 7:44 AM, Francesco Pietra <chiendarret at gmail.com> wrote:
> I wonder whether the advancement in programming would now allow to
> improve on the speed of program "grid", particularly as little use of
> RAM memory is currently made by the program.
>
> With about 10 million grid points I had no problems; completed in a
> couple of hours. With 60 million points (a grid box of 153 110 108 A)
> it may be impracticably too slow. It is only after 600 minutes
> (measured with "top -i") that some percent of protein atoms have
> progressed (a miserable 10%), while comparatively little memory is
> used (3.6% of 24GB) . Clearly th engagement is not linear.
>
> As I want to examine the whole protein, I am thinking to create
> smaller grids for the various parts of the protein, rather than
> re-modeling by cutting parts of the protein away. Right?

That does not seem to be a smart idea. I have now generated the
spheres from the protein pdb, then I selected spheres for a small
portion of the protein, and box accordingly. Now the grid command uses
less memory (0.6% of 24GB) than with 3400 spheres covering the whole
protein (%MEM 3.6). However, grid creation might be equally slow.
After 1 hour, still 0% protein atoms processed. Is there no way to
circumvent the laborious procedure of creating models for parts of the
protein? As a multimer, this procedure is not only laborious but also
unsatisfactory from many view points, in particular for the subsequent
MD simulation. I hoped that grid forgets about the parts of the
protein which lie outside the box.

francesco


>
> Here is the grid script I am using. Could it be adapted to the heavy
> task of this protein while not triggering false docking?
>
> ===============
> grid.in
>
> compute_grids                  yes
> grid_spacing                   0.3
> output_molecule                no
> contact_score                  no
> energy_score                   yes
> energy_cutoff_distance         9999
> atom_model                     a
> attractive_exponent            6
> repulsive_exponent             12
> distance_dielectric            yes
> dielectric_factor              4
> bump_filter                    yes
> bump_overlap                   0.75
> receptor_file /home/francesco/dockwork/dock_charge-53/mod21_r_c.mol2
> box_file  /home/francesco/dockwork/dock_charge-53/mod21_272A_75.pdb
> vdw_definition_file /usr/local/dock6/parameters/vdw_AMBER_parm99.defn
> score_grid_prefix              grid
> =========================
>
>
> Thanks
> francesco pietra
>