DOCK 6 FAQ


General Questions


What is the most current release of DOCK?

The most current release is version 6.2 which was released in March 2008.

Should I upgrade to the most current release?

In general, yes. In particular, bug fixes and basic improvements will make the upgrade worthwhile even if the new functionalities are not desired.

Where do I get the dms program and how much does it cost?

The dms program is distributed by the Computer Graphics Lab at UCSF. It is free of charge. To download a copy of dms, go to this link.

What if I have a question that is not answered here or in the manual?

You can join the dock-fans mailing list to meet and talk with other people who are also interested in DOCK. Please search the archives before asking your question in case it has been asked before.


Installation Questions


How is dms installed ?

The dms program description at the UCSF Computer Graphics Lab and the README file in the dms distribution provide details. Here is a quick start example:
sh < ./dms.shar
cd dms
# Edit GNUmakefile per the README: change LIBDIR and BINDIR
vi GNUmakefile
make install
Some reported problems are caused by invalid LIBDIR and BINDIR definitions. Ensure that these directories actually exist; create them with mkdir if necessary. Search the DOCK-Fans mail archives before posting dms related questions.

What is the status of DOCK on 64 bit platforms ?

We do not yet officially support 64 bit platforms. However, DOCK 6.0 through 6.2 compile when built with the verbatim gnu configuration file: one known problem is that dock6's Zou GB/SA Score crashes when reading the SA grid; another is that sphgen is producing different clustering. We do expect that migration problems from 32 bit to 64 bit platforms are due to assumptions about the sizes integers or pointers, endianness, or mixing of C and Fortran. We plan to correct these problems in a later release.
Sometimes compiler flags can avoid these problems. For example gnu's -m32 sets int and pointer sizes to 32 bits. But this option is not always available [gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52) on an itanium has -m32 in its man page but gcc -m32 fails with cc1: error: invalid option '32'].

When I compile DOCK, I get an _mmolex Undefined symbols error:

g++ -O2 -o dock6 amber_typer.o base_mpi.o base_score.o conf_gen.o dock.o dockmol.o library_file.o master_score.o orient.o score.o simplex.o utils.o score_solvent.o score_amber.o sasa.o score_chemgrid.o nab/nab.a -lm -lpthread
ld: Undefined symbols:
_mmolex
make: *** [dock6] Error 1

What is causing the error and how do I fix it?

DOCK 6 requires a lexical analyzer generator; example Unix command names are lex and flex. All classical Unices have lex. Linuces usually have flex. But this undefined symbol is caused by a missing lexical analyzer generator. (It may be that some users are not installing enough of their Linux.) In particular, dock6/src/dock/nab/lex.mm_options.c either will not exist or will have a size of zero if a lexical analyzer generator is missing.

Here are some suggestions:

When I compile DOCK, I get syntax error before numeric constant:

g++ -c -DBUILD_DOCK_WITH_MPI -DMPICH_IGNORE_CXX_SEEK -I/include -O2 -o amber_typer.o amber_typer.cpp
In file included from /usr/include/mpi.h:1081,
from dock.h:28,
from amber_typer.cpp:1:
/usr/include/mpi++.h:1473: error: syntax error before numeric constant

What is causing the error and how do I fix it?

This error is due to an incompatibility between the configuration of the MPICH2 installation and the configuration of DOCK 6. Because DOCK 6 does not use the MPI C++ bindings, this issue can be avoided by defining the macro MPICH_SKIP_MPICXX. This can be done on the command line via: make -e DOCKBUILDFLAGS='-DMPICH_SKIP_MPICXX' or by modifying the DOCK 6 configuration file config.h directly via an addition to the macro CFLAGS, e.g., CFLAGS= -DBUILD_DOCK_WITH_MPI -DMPICH_IGNORE_CXX_SEEK -DMPICH_SKIP_MPICXX -I$(MPICH_HOME)/include -O2. See MPI C++ Bindings for background information. Note that DOCK 6 does use some MPI C bindings and does not use any MPI Fortran bindings.

When I test or run DOCK with the amber_score, I get a getpdb: can't open file lig.1.amber.pdb error:

cd test/amber_score_1lgu ; make move_ligand.dockout
Reading parm file (1lgu.lig.1.prmtop)
title:
getpdb: can't open file lig.1.amber.pdb
make: *** [move_everything.dockout] Error 1

What is causing the error and how do I fix it?

Known causes are an incorrectly defined AMBERHOME environment variable, a correctly defined AMBERHOME environment variable that points to a faulty AMBER installation, and a correctly defined AMBERHOME environment variable that points to a correct AMBER9 installation. The problem is usually that antechamber uses AMBERHOME to determine which executables to run and to locate executables. This can cause antechamber to fail. (Note that this should be corrected in the 10 release of AMBER.) Thus, one of the steps of the DOCK amber preparation scripts is failing. The error is buried inside one of the amberize_bla.out files. The simplest patch is to undefine AMBERHOME; the amber preparation scripts will then use the default DOCK supplied AMBER programs. A possible cause is a faulty DOCK installation; surprisingly, this cause has not been reported.

When I compile DOCK with Intel compilers, I get a multiple definition of `main' error:

ifort -O2 grid.o score.o score_grid.o grid point.o define.o io.o io_grid.o io_gridf.o mol_prep.o io_receptor.o io_mol2.o io_pdb.o io_ptr.o io_sph.o label.o label_node.o label_chem.o label_vdw.o label_flex.o mol.o search.o transform.o transformf.o parm.o parm_grid.o rotrans.o utility.o vector.o -lm -lpthread -o grid
grid.o(.text+0x0): In function `main':
: multiple definition of `main'
/usr/local/intel-8.0-20040412/lib/for_main.o(.text+0x0): first defined here
/usr/local/intel-8.0-20040412/lib/for_main.o(.text+0x42): In function `main':
: undefined reference to `MAIN__'
make[2]: *** [grid] Error 1

What is causing the error and how do I fix it?

When mixing C and Fortran some compilers automatically give preference to a user defined C main function. Some do not, such as Intel compilers, and that results in link errors for multiple definitions of main. The solution for Intel compilers is to include -nofor_main in the link step. The can be done via DOCKBUILDFLAGS or by modifying the Makefile. In the next release we shall add a new make macro, say LINK_WITHOUT_FORTRAN_MAIN, to facilitate a simple configuration file approach.

When I build DOCK, I get a yacc: Command not found error:

yacc parser.y
make[2]: yacc: Command not found
make[2]: *** [parser.c] Error 127

What is causing the error and how do I fix it?

The tleap program requires a parser generator; example Unix command names are yacc and bison. All classical Unices have yacc. Linuces usually have yacc. But this command not found error is caused by a missing parser generator. (It may be that some users are not installing enough of their Linux.)

Here are some suggestions: