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

Francesco Pietra chiendarret at yahoo.com
Thu Apr 17 02:02:19 PDT 2008


Hi:
To remove any doubt (below) about the importance of max_orientations size, this was increased from 1000 to 10000. Same error message and behavior of CPU/MEM on "top -i" for command dock6 (serial flex run).

Is previous suggestion:

"Some remaining possibilities are a too big selected_spheres.sph
and a bug.  Please determine the size of the sphere file
that does run with dock6 (and report the memory usage using
top by systematically reducing selected_spheres.sph"

still valid in this form? If so, I'll follow these indications. There must be a way out of this issue, unless the memory request is highly exponential. The size of the ligand has increased by a tiny margin.

Thanks
francesco pietra


--- On Wed, 4/16/08, Scott Brozell <sbrozell at scripps.edu> wrote:

> From: Scott Brozell <sbrozell at scripps.edu>
> Subject: Re: Fw: 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: Wednesday, April 16, 2008, 11:11 PM
> Hi,
> 
> On Wed, 16 Apr 2008, Francesco Pietra wrote:
> 
> > I got another message from the debian web list:
> > 
> > >>The std:: would to me make me think C++
> namespace 'std' function
> > >>'bad_alloc'.  So probably a bad_alloc
> function exists in C++ and is
> > >>returning an error.
> > 
> > >It is a standard exception thrown when the new()
> operator fails.
> > >Your running out of RAM, perhaps.
> 
> Yes.
> 
> 
> > >Do you build this program yourself from source?
> > 
> > Yes, it passed OK all tests, both serial and parallel
> and it works fine with smaller ligands.
> > 
> > francesco
> > 
> > --- On Wed, 4/16/08, Francesco Pietra
> <chiendarret at yahoo.com> wrote:
> > 
> > > From: Francesco Pietra
> <chiendarret at yahoo.com>
> > > Subject: Re: Fwd: Re: [Dock-fans] Ligand Docking
> with DOCK6
> > > To: "Scott Brozell"
> <sbrozell at scripps.edu>
> > > Cc: "dock-fans"
> <dock-fans at docking.org>
> > > Date: Wednesday, April 16, 2008, 2:25 PM
> > > Hi:
> > > Having completed the new machine with 8 logical
> 875
> > > opterons and 24GB memory,  using the same two
> raid1 HDD
> > > (with few adjustments, such as shmmax to 24GB and
> stack
> > > size unlimited) of previous machine, I tried
> again the flex
> > > below. Quickly same error (St9bad_alloc) with
> (top -i) CPU
> > > starting at  100%% and MEM% 0 throughout.
> > > 
> > > I posted that error message to the debian web
> list getting
> > > a partial answer, that is reported here
> unabridged:
> > > 
> > > The std:: would to me make me think C++ namespace
> > > 'std' function
> > > 'bad_alloc'.  So probably a bad_alloc
> function
> > > exists in C++ and is
> > > returning an error.
> > > I personally try to avoid dealing with C++ code
> anymore. 
> > > It is get
> > > ting
> > > too ugly after the STL stuff went in.
> > > Try a search for 'C++ bad_alloc' and you
> will find
> > > lots of stuff on
> > > bad_alloc in the C++ std library.  About 45000
> hits in
> > > google.
> > > 
> > > Is that suggesting anything before I go to
> investigate
> > > systematically the mem% vs. sphere_select
> dimensions?
> 
> No.
> 
> 
> > > I recall that with smaller selected_spheres the
> error
> > > message was: Could not complete growth; confirm
> grid box is
> > > large enough   to contain ligand and try
> increasing
> > > max_orients.
> 
> With continuous score the grid box does not exist;
> it is still possible that max_orientations is too small,
> but the value of 1000 makes it very unlikely.
> 
> Scott
> 
> > > Thanks
> > > francesco
> > > 
> > > 
> > > 
> > > 
> > > --- On Tue, 4/8/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: Tuesday, April 8, 2008, 2:49 PM
> > > > Hi,
> > > > 
> > > > On Tue, 8 Apr 2008, Francesco Pietra wrote:
> > > > 
> > > > > $ ulimit -s unlimited only changed in
> > > "ulimit
> > > > -a" output:
> > > > > stack size (k bytes, -s) unlimited
> > > > > 
> > > > > Under these new conditions, command:
> > > > > $ dock6 -i anchor_and_grow_nogrid.in -o
> > > > anchor_and_grow_nogrid.out
> > > > > resulted in a few seconds in:
> > > > > 
> > > > > terminate called after throwing and
> instance of
> > > > 'std::bad_alloc'
> > > > >    what (): St9bad_alloc
> > > > > Aborted
> > > > > 
> > > > > During this procedure
> > > > > 
> > > > > USER        PR  NI  VIRT    RES  
> > > > SHR    S   CPU   MEM   COMMAND
> > > > > francesco  20   0   42048  7476  1448  
> > > > R    100    0    dock6
> > > > 
> > > > Some remaining possibilities are a too big
> > > > selected_spheres.sph
> > > > and a bug.  Please determine the size of the
> sphere
> > > file
> > > > that
> > > > does run with dock6 (and report the memory
> usage using
> > > top)
> > > > by
> > > > systematically reducing
> selected_spheres.sph.
> > > > I ran the continuous score tests using
> valgrind; there
> > > were
> > > > no memory problems detected.  A little
> gooogggling of 
> > > > debian std::bad_alloc 
> > > > didn't find much.  Naturally you should
> verify
> > > that all
> > > > the
> > > > debian/glib/gcc patches have been applied.
> > > > 
> > > > > actually CPU started at 73%, incresed
> to 100%,
> > > then
> > > > died. I am not sure I understand
> > > > > "memory exhausion", though I
> am sure
> > > that
> > > > during this procedure, memory for dock6
> > > > > command did not move from zero.
> > > > 
> > > > I assume that the dock output file still
> contained the
> > > > memory
> > > > exhausted error message.
> > > > 
> > > > Scott
> > > > 
> > > > 
> > > > > RAM on this machine is large because
> recently I
> > > used
> > > > to carry out DFT procedures
> > > > > with large molecules, recent
> functionals, and
> > > > relatively high basis sets.
> > > > > 
> > > > > The in file was as before:
> > > > > 
> > > > >
> > > > ligand_atom_file                            
>          
> > >      
> > > > > /home/francesco/dockwork/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/selected_spheres.sph
> > > > >
> > > > max_orientations                            
>          
> > >      
> > > > 1000
> > > > >
> > > > critical_points                             
>          
> > >      
> > > > no
> > > > >
> > > > chemical_matching                           
>          
> > >      
> > > > no
> > > > >
> > > > use_ligand_spheres                          
>          
> > >      
> > > > no
> > > > >
> > > > flexible_ligand                             
>          
> > >      
> > > > yes
> > > > >
> > > > min_anchor_size                             
>          
> > >      
> > > > 40
> > > > >
> > > > pruning_use_clustering                      
>          
> > >      
> > > > yes
> > > > >
> > > > pruning_max_orients                         
>          
> > >      
> > > > 100
> > > > >
> > > > pruning_clustering_cutoff                   
>          
> > >      
> > > > 100
> > > > >
> > > > use_internal_energy                         
>          
> > >      
> > > > yes
> > > > >
> > > > internal_energy_att_exp                     
>          
> > >      
> > > > 6
> > > > >
> > > > internal_energy_rep_exp                     
>          
> > >      
> > > > 12
> > > > >
> > > > internal_energy_dielectric                  
>          
> > >      
> > > > 4.0
> > > > >
> > > > use_clash_overlap                           
>          
> > >      
> > > > no
> > > > >
> > > > bump_filter                                 
>          
> > >      
> > > > no
> > > > >
> > > > score_molecules                             
>          
> > >      
> > > > yes
> > > > >
> > > > contact_score_primary                       
>          
> > >      
> > > > no
> > > > >
> > > > contact_score_secondary                     
>          
> > >      
> > > > no
> > > > >
> > > > grid_score_primary                          
>          
> > >      
> > > > no
> > > > >
> > > > grid_score_secondary                        
>          
> > >      
> > > > no
> > > > >
> > > > dock3.5_score_primary                       
>          
> > >      
> > > > no
> > > > >
> > > > dock3.5_score_secondary                     
>          
> > >      
> > > > no
> > > > >
> > > > continuous_score_primary                    
>          
> > >      
> > > > yes
> > > > >
> > > > continuous_score_secondary                  
>          
> > >      
> > > > no
> > > > >
> > > > cont_score_rec_filename                     
>          
> > >      
> > > > > /home/francesco/dockwork/protein.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
> > > > >
> > > > gbsa_zou_score_secondary                    
>          
> > >      
> > > > no
> > > > >
> > > > gbsa_hawkins_score_secondary                
>          
> > >      
> > > > no
> > > > >
> > > > amber_score_secondary                       
>          
> > >      
> > > > no
> > > > >
> > > > minimize_ligand                             
>          
> > >      
> > > > yes
> > > > >
> > > > minimize_anchor                             
>          
> > >      
> > > > yes
> > > > >
> > > > minimize_flexible_growth                    
>          
> > >      
> > > > yes
> > > > >
> > > > use_advanced_simplex_parameters             
>          
> > >      
> > > > no
> > > > >
> > > > 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_anchor_max_iterations               
>          
> > >      
> > > > 500
> > > > >
> > > > simplex_grow_max_iterations                 
>          
> > >      
> > > > 500
> > > > >
> > > > 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                       
>          
> > >      
> > > > flex
> > > > >
> > > > write_orientations                          
>          
> > >      
> > > > no
> > > > >
> > > > num_scored_conformers                       
>          
> > >      
> > > > 1
> > > > >
> > > > rank_ligands                                
>          
> > >      
> > > > no
> > > > > 
> > > > > Now, with memory slots and HDs from 
> this
> > > machine,
> > > > and second hand additional
> > > > > material, I am trying to assemble an 8
> CPUs
> > > shared
> > > > memory (total 24GB). If lucky,
> > > > > I'll also have to reinstall the OS
> and
> > > > applications. All that in spare time.
> > > > > Nevertheless,  succeeding with
> Dock/Amber with
> > > the
> > > > above large ligands is my primary
> > > > > interest at this time.


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


More information about the Dock-fans mailing list