[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