[Dock-fans] Fwd: Re: Ligand Docking with DOCK6
Scott Brozell
sbrozell at scripps.edu
Tue Apr 8 14:49:00 PDT 2008
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.
More information about the Dock-fans
mailing list