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

Francesco Pietra chiendarret at yahoo.com
Thu Apr 17 07:04:07 PDT 2008


Hi:
To add that the debian-list subscriber who yesterday replied about bad_alloc, asking how the program was compiled, is doubtful about the correctness of the compilation, though I said that tests and docking with smaller ligands are OK. His post today:

>> Do you build this program yourself from source?
>
>Yes (g77-3.4 g++ 4.1.2 lib2c0-dev) from the configure file provided by
>developers. No errors in either the serial or parallel compilations
>(openmpi). Also, there is a very long test for both the serial and
>parallel execution. All passed with a few marginal warnings for
>different precision on different machines. Finally, docking of a
>slightly smaller ligands occurs with no errors.

I'd build with debug info and run it under gdb and/or valgrind.  Might
tell you where it is messing up.
___________

Do you believe worth while to follow his advice? If so, any web indication where to learn about compiling "with debug info and run it under gdb and/or valgrind"

Thanks

francesco


--- On Thu, 4/17/08, Francesco Pietra <chiendarret at yahoo.com> wrote:

> From: Francesco Pietra <chiendarret at yahoo.com>
> Subject: Re: Fw: 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: Thursday, April 17, 2008, 2:02 AM
> 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


      ____________________________________________________________________________________
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