[Dock-fans] Fwd: Re: Ligand Docking with DOCK6
Francesco Pietra
chiendarret at yahoo.com
Wed Apr 16 14:25:33 PDT 2008
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?
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.
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