A consistent interface is used, at least for the main program suite. The order for command parameters is generally given in this form:
program [conformation-file | conformation-pair-file | conformation-file-list | conformation-pair-file-list | input-file | input-file-list] [scoring-function-file | parameter-file] [output-file | output-file-prefix | output-file-suffix] [other-arguments]
is generally a PDB format file; sometimes a DSSP format file is used. If containing the extension
.pdb, then a single file is assumed; else multiple conformations are assumed (in some cases)
is a file containing a list of multiple conformation files (in general, a
file-listis a file containing a list of files)
contains the relevant scoring function
is any other parameter-file
is the name of the output-file; if omitted and there is no requirement for multiple output files, then
stdoutwill be used to generate a new
is the prefix used when multiple output files are generated
is the suffix used when multiple output files are generated
any other arguments.
In addition, each program may have its own options and parameters. Typing the name of the program will give some help. The common interface options are:
-c conformation-file-list|conformation-file -i input-file -o output-file
In cases where the above options are irrelevant, the program will make
an attempt to adhere to the philosophy of the above approach as much
as possible. For example,
plot_scores will take a file containing a list of pairs
of group names, or just two group names. In general, an attempt will
be made to be able to specify the output file in an optional manner
(i.e., explicit vs. redirection to
stdout). Similarly, if
there is only one input argument, or for programs for which such a
function would be useful, an attempt will be made to read from
stdin. All errors and informational messages will be sent to
stderr (these can be redefined in
Reading multiple input files is not possible unless a single output file is generated for the entire set of input files, or when multiple output files are generated for a single input file.
Typing the name of the program without any arguments or with an
excess number of arguments (in cases where standard input is expected)
will give you the usage information, including the set of parametres
used during compilation. The display of parametres, and reporting of
progress as a program does its job, can be disabled or enabled
(default) by turning off or on the
VERBOSE flag in
ramp/src/common/defines.h and recompiling the entire suite.
Additional debugging can be enabled or disabled (default) by turning
DEBUG flag in
recompiling the entire suite.
The following terms are used interchangeably at times:
score - energy - probability
ramp/bin/scripts - architecture-independent executables ramp/bin/architecture - architecture dependent executables; four architectures are supported: linux_alpha, linux_ix86, irix_mips, and osf1_alpha. ramp/doc - documentation ramp/src - source ramp/src/common - common routines used by several programs ramp/src/mc_commom - common main chain routines used by several programs ramp/src/mcgen - main chain generation programs ramp/src/music - music related programs ramp/src/obsolete - obsolete source; this directory contains code for stuff that is incomplete, being worked on, or ideas that didn't pan out. ramp/src/potentials - scoring functions ramp/src/scores - scoring function related programs ramp/src/sc_common - common side chain routines used by several programs ramp/src/scgen - side chain generation programs ramp/lib - parameter files ramp/lib/folds - fold libraries ramp/lib/scoring_functions - parametres for scoring functions
BINDIR_EXTENSION - architecture dependent binary directory names. HDRS - list of paths for includes for compilation purposes RAMP_ROOT - top level directory for the RAMP source/executable directory tree
I have a test set that will verify a program in the RAMP suite against previously obtained results. Unfortunately it's not ready for distribution yet.
To test the scoring functions generally, the Decoys 'R Us decoy database may prove useful.
Most, but not all, programs in the suite require residues to be
numbered consecutively starting from 1. Behaviour is unpredictable
otherwise. PDB files do not come like this always. So the solution is
to normally use
on the PDB file and then have it used by the other software.