[Dock-fans] Fw: Re: Fw: Re: Fwd: Re: Ligand Docking with DOCK6
Francesco Pietra
chiendarret at yahoo.com
Thu Apr 17 10:21:34 PDT 2008
forgot To address
--- On Thu, 4/17/08, Francesco Pietra <chiendarret at yahoo.com> wrote:
> From: Francesco Pietra <chiendarret at yahoo.com>
> Subject: Fw: Re: Fw: Re: Fwd: Re: [Dock-fans] Ligand Docking with DOCK6
> To:
> Cc: "dock-fans" <dock-fans at docking.org>
> Date: Thursday, April 17, 2008, 7:04 AM
> 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
____________________________________________________________________________________
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