[Dock-fans] Fwd: Re: Ligand Docking with DOCK6
Scott Brozell
sbrozell at scripps.edu
Mon Mar 31 16:02:17 PDT 2008
Hi,
On Tue, 18 Mar 2008, Francesco Pietra wrote:
> Thanks a lot for the suggestion. I remain with at least a couple of doubts,
> i.e., how to fulfill the need for continuous score (manual 2.8.5) "Regardless
> of the exponent used, the same radii and well-depths are used". If that can be
That statement refers to the vdw parameters, and its intention is that
grid input key vdw_definition_file and dock input key vdw_defn_file
can be specified to the same file. I'll clarify the manual.
> adjusted at a first sight, please check the input file (rigid_noscore.in) for
> the intended rigid docking without using grid. Following the input file are
> listed parameters that I used for grid (which was OK for smaller ligands). Data
> for flex are also shown. Please, disregard them.
>
> rigid_noscore.in:
>
> ligand_atom_file /home/francesco/....../ctc_lig_min43.mol2
> limit_max_ligands no
> skip_molecule no
> read_mol_solvation no
> calculate_rmsd no
> orient_ligand yes
> automated_matching yes
> receptor_site_file /home/francesco/....../selected_spheres.sph
> max_orientations 1000
> critical_points no
> chemical_matching no
> use_ligand_spheres no
> flexible_ligand no
> bump_filter no
> score_molecules yes
> contact_score_primary no
> contact_score_secondary no
> grid_score_primary no
> grid_score_secondary no
> grid_score_rep_rad_scale
> grid_score_vdw_scale
> grid_score_es_scale
> grid_score_grid_prefix
> dock3.5_score_secondary
> continuous_score_primary yes
> continuous_score_secondary no
> cont_score_rec_filename /home/francesco/......./teepee_HOH.mol2
> cont_score_att_exp 6
> cont_score_rep_ex 12
> cont_score_dielectric 4.0
> cont_score_vdw_scale 1
> cont_score_es_scale 1
> gbsa_zou_score_secondary no
> gbsa_hawkins_score_secondary no
> amber_score_primary no
> amber_score_secondary no
> minimize_ligand yes
> simplex_max_iterations 1000
> simplex_max_cycles 1
> simplex_score_converge 0.1
> simplex_cycle_converge 1.0
> simplex_trans_step 1.0
> simplex_rot_step 0.1
> simplex_tors_step 10.0
> simplex_final_min no
> simplex_random_seed 0
> atom_model all
> vdw_defn_file /usr/local/dock6/parameters/vdw_AMBER_parm99.defn
> flex_defn_file /usr/local/dock6/parameters/flex.defn
> flex_drive_file /usr/local/dock6/parameters/flex_drive.tbl
> ligand_outfile_prefix rigid_nogrid
> write_orientations no
> num_scored_conformers_written 1
> rank_ligands no
Add these:
cont_score_rep_rad_scale 1
cont_score_use_dist_dep_dielectric yes
> _______________
>
> dms teepee_noH.pdb -n -w 1.4 -v -o rec.ms
> ______________
>
> INSP:
>
> rec.ms
> R
> 0.0
> 4.0
> 1.4
> rec.sph
> _____
>
> sphere_select -i rec.sph -c teepee_noH.pdb -a 3421 -r 25.0
>
> where 3421 is the atom number where the sphere of radius 25A was centered.
> Where to set this 25A, and what about the well depth?
This step is for characterization of the active site and should
not be changed for an equal substitution of continuous_score_primary
for grid_score_primary. What well depth ?
Continuous versus grid scoring is discussed in
http://dock.compbio.ucsf.edu/DOCK_6/dock6_manual.htm#MengetalJCompChem1992
Scott
> ___________
> sphgen_cpp_cluster1.in:
>
> rec.sph
> 1
> N
> sphgen_cpp_cluster1.pdb
> ________________________-
>
> showbox:
>
> y
> 10.0
> rec.sph
> rec_box.pdb
> ____________
>
> 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/grid/teepee_HOH.mol2
> box_file /home/francesco/dockwork/grid/rec_box.pdb
> vdw_definition_file /usr/local/dock6/parameters/vdw_AMBER_parm99.defn
> score_grid_prefix grid
>
>
> --- Scott Brozell <sbrozell at scripps.edu> wrote:
> > Ok, thanks for the updated report; we are keeping memory tuning
> > on our todo list.
> >
> > Here is an idea off the top of my head: try
> > grid_score_primary no
> > continuous_score_primary yes
> > This may trade cputime for memory.
> > Study the manual to keep the dock and grid settings consistent:
> > http://dock.compbio.ucsf.edu/DOCK_6/dock6_manual.htm#ContinuousScore
> >
> > If this works then there are definitely some easy cputime tunings
> > for continuous_score.
> >
> > Scott
> >
> > On Fri, 14 Mar 2008, Francesco Pietra wrote:
> >
> > > Forgot to add that with Dock6.1 I had also tried with a smaller box. Rigid
> > dock
> > > went on, while flex failed with the warning "could not complete growth;
> > confirm
> > > grid box is large enough to contain ligand and try increasing max_orients".
> > > Increasing max_orient was not a solution. In other words, I was faced by
> > either
> > > having too many points or a spatially inadequate room for my things. The
> > trial
> > > below with Dock 6.2 was for the large box and large sphere, 25A, which
> > embraces
> > > the whole molecular system.
> > >
> > > --- Francesco Pietra <chiendarret at yahoo.com> wrote:
> > > > Date: Fri, 14 Mar 2008 02:30:58 -0700 (PDT)
> > >
> > > > The issue Orient: :match_ligand huge memory requirement (for large
> > ligands)
> > > > probably is not solved by DOCK v 6.2.
> > > >
> > > > I recall that with 106 CHO atoms, all scoring, including Amber rescore,
> > went
> > > > to
> > > > completion with DOCK v 6.1. In contrast, with same-family ligand of 118
> > CHO
> > > > atoms,the above issue arose already at the first stage of rigid dock. I
> > used
> > > > Andrew Magis' software for creating and selecting sphere, as the software
> > of
> > > > DOCK was unable to deal with so many points.
> > > >
> > > > I have tried now again with DOCK v 6.2 on the same machine (Debian Linux,
> > > > OpenMPI pointing to MPICH2, four cpu, 4GB memory per cpu, which, for
> > > > dual-opteron shared memory, means a total of 16GB ram available. Same
> > failure
> > > >
> > > > on
> > > >
> > > > mpirun -np 4 rigid.in rigid.out
> > > >
> > > > I add the input and screen outputs for documentation (and hopefully aid
> > in
> > > > circumventing the issue);
> > > >
> > > > RIGID.IN
> > > > ligand_atom_file /home/francesco/dockwork/ligand_dock62/lig_min43.mol2
> > > > limit_max_ligands no
> > > > skip_molecule no
> > > > read_mol_solvation no
> > > > calculate_rmsd no
> > > > orient_ligand yes
> > > > automated_matching yes
> > > > receptor_site_file
> > > > /home/francesco/dockwork/ligand_dock62/selected_spheres.sph
> > > > max_orientations 1000
> > > > critical_points no
> > > > chemical_matching no
> > > > use_ligand_spheres no
> > > > flexible_ligand no
> > > > bump_filter no
> > > > score_molecules yes
> > > > contact_score_primary no
> > > > contact_score_secondary no
> > > > grid_score_primary yes
> > > > grid_score_secondary no
> > > > grid_score_rep_rad_scale 1
> > > > grid_score_vdw_scale 1
> > > > grid_score_es_scale 1
> > > > grid_score_grid_prefix /home/francesco/dockwork/ligand_dock62/grid
> > > > dock3.5_score_secondary no
> > > > continuous_score_secondary no
> > > > gbsa_zou_score_secondary no
> > > > gbsa_hawkins_score_secondary no
> > > > amber_score_secondary no
> > > > minimize_ligand yes
> > > > simplex_max_iterations 1000
> > > > simplex_max_cycles 1
> > > > simplex_score_converge 0.1
> > > > simplex_cycle_converge 1.0
> > > > simplex_trans_step 1.0
> > > > simplex_rot_step 0.1
> > > > simplex_tors_step 10.0
> > > > simplex_final_min no
> > > > simplex_random_seed 0
> > > > atom_model all
> > > > vdw_defn_file /usr/local/dock6/parameters/vdw_AMBER_parm99.defn
> > > > flex_defn_file /usr/local/dock6/parameters/flex.defn
> > > > flex_drive_file /usr/local/dock6/parameters/flex_drive.tbl
> > > > ligand_outfile_prefix rigid
> > > > write_orientations no
> > > > num_scored_conformers_written 1
> > > > rank_ligands no
> > > >
> > > > SCREEN.OUT
> > > > Initializing MPI Routines...
> > > > Initializing MPI Routines...
> > > > Initializing MPI Routines...
> > > > Initializing MPI Routines...
> > > > terminate called after throwing an instance of 'std::bad_alloc'
> > > > what(): St9bad_alloc
> > > > [deb64:04547] *** Process received signal ***
> > > > [deb64:04547] Signal: Aborted (6)
> > > > [deb64:04547] Signal code: (-6)
> > > > [deb64:04547] [ 0] /lib/libpthread.so.0 [0x2b242c453410]
> > > > [deb64:04547] [ 1] /lib/libc.so.6(gsignal+0x3b) [0x2b242c58b07b]
> > > > [deb64:04547] [ 2] /lib/libc.so.6(abort+0x10e) [0x2b242c58c84e]
> > > > [deb64:04547] [ 3]
> > > >
> > /usr/lib/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x114)
> > > > [0x2b242c0f6424]
> > > > [deb64:04547] [ 4] /usr/lib/libstdc++.so.6 [0x2b242c0f45a6]
> > > > [deb64:04547] [ 5] /usr/lib/libstdc++.so.6 [0x2b242c0f45d3]
> > > > [deb64:04547] [ 6] /usr/lib/libstdc++.so.6 [0x2b242c0f46ba]
> > > > [deb64:04547] [ 7] dock6.mpi [0x42c654]
> > > > [deb64:04547] [ 8] /usr/lib/libstdc++.so.6(_Znwm+0x34) [0x2b242c0f4954]
> > > > [deb64:04547] [ 9] /usr/lib/libstdc++.so.6(_Znam+0x9) [0x2b242c0f4a49]
> > > > [deb64:04547] [10] dock6.mpi(_ZN6Orient12match_ligandER7DOCKMol+0x33d)
> > > > [0x44b9bd]
> > > > [deb64:04547] [11] dock6.mpi(main+0x90a) [0x42cf6a]
> > > > [deb64:04547] [12] /lib/libc.so.6(__libc_start_main+0xda)
> > [0x2b242c5784ca]
> > > > [deb64:04547] [13] dock6.mpi(__gxx_personality_v0+0xba) [0x41bf9a]
> > > > [deb64:04547] *** End of error message ***
> > > > mpirun noticed that job rank 0 with PID 4546 on node deb64 exited on
> > signal
> > > > 15
> > > > (Terminated).
> > > > 3 additional processes aborted (not shown)
> > > >
> > > > Thanks a lot for examining this report
> > > >
> > > > francesco pietra
> > > >
> > > > --- Scott Brozell <sbrozell at scripps.edu> wrote:
> > > > > On Fri, 15 Feb 2008, Francesco Pietra wrote:
> > > > >
> > > > > > In order to plan my work, may I ask if Dock6.2 has reduced the memory
> > use
> > > > > of
> > > > > > Orient::match_ligand? If the answer is already implied in your last
> > few
> > > > > mails,
> > > > > > I beg pardon.
> > > > >
> > > > > Possibly, some memory related improvements have been made.
> > > > >
> > > > > Scott
> > > > >
> > > > > > --- Scott Brozell <sbrozell at scripps.edu> wrote:
> > > > > >
> > > > > > > On Wed, 13 Feb 2008, Christian Schudoma wrote:
> > > > > > >
> > > > > > > > I am a PhD student in structural bioinformatics, trying to use
> > DOCK6
> > > > > for
> > > > > > > > docking ligands into RNA molecules, in particular riboswitches.
> > Are
> > > > the
> > > > >
> > > > > > > > DOCK6 scoring functions suitable for this task, i.e. have
> > NA-specific
> > > >
> > > > > > > > parameters been integrated into the latest DOCK version? In the
> > > > > > > > dockfans-archives I found a brief statement (Feb 2005) that
> > > > comparison
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://shoichetlab.compbio.ucsf.edu/pipermail/dock-fans/2005-February/000038.html
> > > > > > > > of "a variety of charge models for RNA" have been under way. Have
> > > > these
> > > > >
> > > > > > > > comparisons been fruitful? I wasn't able to find further or even
> > > > > > > > concluding information about this even after intensive research.
> > > > > > > >
> > > > > > > > If such modifications have not been made yet, does anyone have
> > > > > > > > experience with successfully docking to RNA targets and is
> > willing to
> > > >
> > > > > > > > share their parameters/scoring settings? Any help would be
> > > > appreciated!
> > > > > > > > (I already know about the article by Kang et al. (2003) =) )
> > > > > > >
> > > > > > > The test set used for "DOCK 6", which will be available after 6.2
> > > > > > > is released, is an RNA suite. And it includes some riboswitches.
> > > > > > > As far as RNA's, 6.1 is essentially the same as 6.2 except for
> > Amber
> > > > > score.
> > > > > > > There will be some new scripts to handle RNAs for Amber score.
> > > > > > > (In 6.1 and 6.0 the amberize scripts assume that an NA is a DNA.)
> > > > > > > 6.2 will be released very soon.
> > > > > > >
More information about the Dock-fans
mailing list