[Dock-fans] Fwd: Re: Ligand Docking with DOCK6

Scott Brozell sbrozell at scripps.edu
Mon Apr 7 21:42:49 PDT 2008


Hi,

On Fri, 4 Apr 2008, Francesco Pietra wrote:

> Collected here are answers to the questions posed below. Additional info is provided
> about kernel code, heap, and mem. On a separate mail I reported failure to batch
> run: it was caused by running sysstat. OK when sysstat was stopped.

Ok, probably command line syntax for -o.  Maybe this would work:
sysstat ( dock6 -i foo -o bar )


> $ ulimit -a:
> 
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> max nice                        (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) unlimited
> max locked memory       (kbytes, -l) unlimited
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) unlimited
> max rt priority                 (-r) 0
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) unlimited
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited


The item that is suspiciously small is the stack size.
Did you try to increase it already ?
$ ulimit -s unlimited

> ls -ls:
> 
> 123608  -rw-r--r-- 1 francesco francesco 126441016 2008-04-02 grid.nrg
>  10308  -rw-r--r-- 1 francesco francesco  10536782 2008-04-02 grid.bmp
>     40  -rw-r--r-- 1 francesco francesco     37088 2008-04-02 selected_spheres.sph

These grids are not big.
But the sphere file is not small.


> During the few seconds that the  procedure was active

So I gather that dock6 terminated with a memory exhausion as you 
have indicated previously ?


> PID    USER      PR NI VIRT   RES   SHR S %CPU %MEM COMMND
> 3643  francesco  15  0 10596  7484  960  R  73 0.0    top

The command is top; you need to report this line for command dock6!


Your machine has lots of memory.  So the memory exhausion is curious.

Scott


> $ kernel:
> 91:Memory: 16432744k/17825792k available (1929k kernel code, 343044k
> reserved, 864k data, 176k init) 309:Freeing unused kernel memory: 176k freed
> 
> $ cat /proc/self/maps
> 00400000-00405000 r-xp 00000000 09:02 1700624                            /bin/cat
> 00504000-00505000 rw-p 00004000 09:02 1700624                            /bin/cat
> 00505000-00526000 rw-p 00505000 00:00 0                                  [heap]
> 2b7bdc138000-2b7bdc14f000 r-xp 00000000 09:02 1471913                   
> /lib/ld-2.3.6.so
> 2b7bdc14f000-2b7bdc151000 rw-p 2b7bdc14f000 00:00 0
> 2b7bdc24e000-2b7bdc250000 rw-p 00016000 09:02 1471913                   
> /lib/ld-2.3.6.so
> 2b7bdc250000-2b7bdc371000 r-xp 00000000 09:02 1471926                   
> /lib/libc-2.3.6.so
> 2b7bdc371000-2b7bdc471000 ---p 00121000 09:02 1471926                   
> /lib/libc-2.3.6.so
> 2b7bdc471000-2b7bdc486000 r--p 00121000 09:02 1471926                   
> /lib/libc-2.3.6.so
> 2b7bdc486000-2b7bdc489000 rw-p 00136000 09:02 1471926                   
> /lib/libc-2.3.6.so
> 2b7bdc489000-2b7bdc48f000 rw-p 2b7bdc489000 00:00 0
> 2b7bdc48f000-2b7bdc5b7000 r--p 00000000 09:03 948498                    
> /usr/lib/locale/locale-archive
> 7fffce95c000-7fffce972000 rw-p 7fffce95c000 00:00 0                      [stack]
> ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]
> 
> $ cat /proc/meminfo:
> MemTotal:     16438048 kB
> MemFree:      16335060 kB
> Buffers:          4816 kB
> Cached:          37892 kB
> SwapCached:          0 kB
> Active:          42756 kB
> Inactive:        17764 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> LowTotal:     16438048 kB
> LowFree:      16335060 kB
> SwapTotal:     6835576 kB
> SwapFree:      6835576 kB
> Dirty:               0 kB
> Writeback:           0 kB
> AnonPages:       17672 kB
> Mapped:           7112 kB
> Slab:            19932 kB
> PageTables:       1316 kB
> NFS_Unstable:        0 kB
> Bounce:              0 kB
> CommitLimit:  15054600 kB
> Committed_AS:    40972 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed:      3932 kB
> VmallocChunk: 34359734427 kB
> 
> Hope this suffices.
> Thanks
> francesco
> 
> 
> 
> 
> --- On Thu, 4/3/08, Scott Brozell <sbrozell at scripps.edu> wrote:
>       From: Scott Brozell <sbrozell at scripps.edu>
>       Subject: Re: Fwd: Re: [Dock-fans] Ligand Docking with DOCK6
>       To: "Francesco Pietra" <chiendarret at yahoo.com>
>       Cc: "dock-fans" <dock-fans at docking.org>
>       Date: Thursday, April 3, 2008, 2:23 PM
> 
> Hi,
> On Wed, 2 Apr 2008, Francesco Pietra wrote:
> > With Dock v. 6.2, I run serial interactive
> > $ dock6 -i rigid_nogrid.in
> > where the in file was added of
> > cont_score_rep_rad_scale   1
> > cont_score_use_dist_dep_dielectric
>  yes
> > as printed below:
> > 
> > ligand_atom_file /home/francesco/dockwork/ctx3c_dock62/ligand.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/ctx3c_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   no
> > grid_score_secondary  no
> > grid_score_rep_rad_scale no
> > grid_score_vdw_scale   no
> > grid_score_es_scale   no
> > grid_score_grid_prefix no
> > dock3.5_score_secondary no
> > continuous_score_primary yes
> > continuous_score_secondary no
> >
>  cont_score_rec_filename /home/francesco/dockwork/ctx3c_dock62/protein.mol2
> > cont_score_rep_rad_scale  1
> > cont_score_use_dist_dep_dielectric yes
> > 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
> > 
> > accepting defaults. A statement was also presented which was not in the in
> file:
> > 
> > num_scored_conformers  [1]
> Yes num_scored_conformers replaced num_scored_conformers_written in 6.2.
> It is useful to first try old inputs interactively when the DOCK version
> has been updated to underscore input changes.
> > I accepted the [1] default..
> > 
> > It run out of memory:
> > 
> > Initialing Library File Routines ...
> > Initializing Orienting Routines...
> > Error: memory exhausted!
> > If this occurs during grid reading then a likely cause is a
>  grid that is
> too large.
> > Some machines have a very restrictive policy on allocating available
> resources: For
> > Unix platforms increase the datasize, stacksize, and memoryuse using the
> limit,
> > ulimit, or unlimit commands; use trial and error to find the apt one of
> the
> > commands.
> > 
> > terminate called after throwing an instance of 'std::bad_alloc'
> > what(): St9bad_alloc
> > Aborted
> > _______-
> > It was not reading grid. I use Debian Linux amd64. The memory is set with
> shmmax and
> > when computing with nwchem all 16GB available are used.
> > 
> > Command
> > ulit
> > repots
> > unlimited
> Huh, what is the complete output of the limit command ?
> What are the sizes of your grid and sphere files; use ls -ls
> Run dock6 and send the top output for that process; see below.
> > I did nothing recently about "datasize" "stacksize".
> Should I
>  investigate about
> > these?
> Definitely, isn't that clear from the error message ?
> This error message seems clear to me, and I wonder why it is ignored:
> http://blur.compbio.ucsf.edu/pipermail/dock-fans/2008-March/001468.html
> I have confirmed that continuous score will substitute for grid score
> in flexible docking.  Here are some memory highlights:
> cd dock6/install/test/grid_score
> ../../../bin/dock6 -i grid2.dockin -o grid2.dockout
> top  shows
>   PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>  23224 srb 17 0 43464 3352 1652 R 99 0.0 0:01.35 dock6
> with the verbatim dock6/install/test/grid_generation
> grid_spacing                   0.5
>    356 -rw-r--r-- 1 srb appl    359152 Apr  3 15:55 grid.nrg
> Radically increasing the size of the grid:
>   4031  sb 18 0 337m 298m 1652 R 80 3.7 0:01.18 dock6
> grid_spacing                   0.05
> 302848 -rw-r--r-- 1          309805888 Apr  3 15:41
>  grid.nrg
> For continuous score 
>  22689 srb 25 0 44848 4808 1696 R 100 0.1 0:06.96 dock6
> grid2.dockin input files diff
> 24c24
> < grid_score_primary                                           yes
> ---
> > grid_score_primary                                           no
> 26,29c26
> < grid_score_rep_rad_scale                                     1
> < grid_score_vdw_scale                                         1
> < grid_score_es_scale                                          1
> < grid_score_grid_prefix                                      
> ../grid_generation/grid
> ---
> > dock3.5_score_primary                                        no
> 30a28
> > continuous_score_primary                                     yes
> 31a30,37
> > cont_score_rec_filename                                      rec.mol2
> > cont_score_att_exp                                           6
> > cont_score_rep_exp   
>                                         12
> > cont_score_rep_rad_scale                                     1
> > cont_score_use_dist_dep_dielectric                           yes
> > cont_score_dielectric                                        4.0
> > cont_score_vdw_scale                                         1
> > cont_score_es_scale                                          1
> Scott



More information about the Dock-fans mailing list