[Dock-fans] Generating grid for big molecules

[Francesco Pietra]

I must somewhat correct myself. Please see below.

On Wed, Sep 24, 2008 at 7:40 PM, Francesco Pietra <chiendarret at gmail.com> wrote:
> 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.

That is wrong. For 3400 sphere (encompassing the whole protein), 10%
examination took 10 hours. For 427 sphere selected for the same
protein, 10% examination took 2 hours. 427 spheres are from 10,000,000
grid points. With such a number of grid points for smaller models,
where the spheres encompassed the whole model, two hours were enough
to complete the grid. Therefore, there is a burden from the protein
not selected within the box.

francesco

> After 1 hour, still 0% protein atoms processed. Is there no way to
> circumvent the laborious procedure of creating models for parts of theI want to check all the protein (a big multimer) for docking a small, non peptidic molecule. I believe I have good reals
sons to try that.

At 0.3A grid_spacing, selecting all the spheres (3500) too many grid
points (60,000,000). Then I selected a portion (437 spheres, 9,500,00
grid points). grid still impracticably too slow.

I have already generated
> 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
>>
>