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-file-pair | conformation-file-list | conformation-file-pair-list | input-file | input-file-list]
[scoring-function-file | parameter-file]
[output-file | output-file-prefix | output-file-suffix]
[other-arguments]
where
conformation-file
conformation-file-list
scoring-function-file
parameter-file
output-file
stdout will be used to generate a new
conformation-file
output-file-prefix
output-file-suffix
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
ramp/src/common/common.h).
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
on the DEBUG flag in ramp/src/common/defines.h and
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
clean_pdb first
on the PDB file and then have it used by the other software.