
Next: Edit
Up: Menus
Previous: Menus
The Open menu leads to a sub-menu that requests the type of file to read
in. Spock will respond differently to different types of files. In any
case, a file selection dialog box will be displayed, which will allow the
user to select the file they wish to read. In some cases, the list of
files is ``filtered'' in that only files with the proper extension are
displayed, e.g. .pdb for PDB files. The filter can be changed via
the Filter button, if the file desired does not have the customary
extension. Initially, for both the ``Open'' and ``Save'' options, spock
will attempt to read the environment variables for the appropriate
directories to use for each type of file (See §3). If these
variables are not set, spock will use the default directory. If you
change the directory for a file type by reading in a file from a different
directory, spock will remember that directory as the new default directory
for that file type.
This option reads in a spock session file. Session files save the vast
majority of the current spock state--atom coordinates, properties,
surfaces, 3D Contours, pretty much everything. In most cases, reading a
saved session file will allow you to resume working right where you left
off. Session files may not be compatible between different versions of
spock, but every attempt has been made to allow the different versions to
share data. However, since these are binary files, they may not be shared
across different operating systems or machine types. Spock attempts to
detect incompatibilities in operating systems, but may not always be
successful, and reading in a session file from an incompatible system
could cause a crash.
This option reads in a spock view file. Numbered view files (
.spview0 through .spview9 are accessible through the View menu.
This option allows support for any number of view files. View files may
also be read with the read= command, as long as the extension on the
file is .spv. See also the view= and saveview= commands
(§5.2.3).
Reads a PDB-format file. When spock reads a PDB file, it assigns a new
molecule number for each chain, or at every ``TER'' record of the PDB
file. Bonding information is calculated based on simple distance
constraints, unless there are ``CONECT'' records for those atoms in the
PDB file. If present, ``HELIX'', ``SHEET'' and ``TURN'' records are read
and processed. Crystal parameters are also read for symmetry operations.
From these records, the secondary structure information is set (as if by
the set structure command or the secondary structure editor §
6.7.6, and helices and sheets for the helix and sheet axis
cylinders are defined (See §6.4.8 and 6.4.9).
For NMR or theoretical structures, each ``MODEL'' record generates a new
model number for selection with the model=n command. Some summary
information is printed, including a list of all currently defined
molecules (generated by an internal call to the mlist command, §
5.2.2). The newly-read bonds, atoms, and worms, are
assigned colors according to the default coloring scheme. Finally, the
new molecules are added to the display. Spock contains limited
support for the alternate position indicator via the altloc
selection string. Many external programs (like AMBER) will be confused by
proteins with multiple conformations.
If present, the ``CONECT'' records may have several effects. First, they
may specify bonding for heteroatom groups. Also, they may specify
hydrogen bonds, so spock will create hydrogen bonds based on this
information if available. Finally, salt bridges may be specified in the
CONECT records. Spock defines an intensity interaction §
6.4.12 for each salt bridge, and sets the intensity to
1.0. If hydrogen bonding or salt bridge information are given in the PDB
file, spock prints a message to that effect.
Finally, note that some parts of spock expect PDB files to conform to the
standard specifications as described by Brookhaven. Although strict
conformance to the standard is not absolutely enforced, some modules won't
work properly with non-standard PDB files. In particular, the hydrogen
bond calculation routines expect standard PDB files, and some worm
rendering styles do as well. If you experience problems with either of
these features, first check that your PDB file conforms to the standard.
The PDB standard specifies that the atom ordering for a residue is
N, CA, C, O followed by the side chain. Some programs (XPLOR,
AMBER) produce PDB files that don't follow this convention. This may
cause problems with hydrogen bond calculations or secondary structure
display. Use a PDB-cleaning program to re-organize your PDB files first.
Note that spock attempts to compensate for these problems, but is not
always successful, particularly if there is more than one PDB file loaded,
some of which conforms to the standard, and some of which do
not.
This option re-reads the .spockrc initialization file (§
3.8) and executes it.
This option reads a spock history file and executes the instructions
contained in it. See §7.
This option reads the from
the hydrogen bonding calculation program HBPLUS (
http://www.biochem.ucl.ac.uk/ mcdonald/hbplus/home.html). This option
is a holdover from the time when spock didn't calculate hydrogen bonds
itself. Currently, it's probably easier for spock to do the calculations
itself (§6.7.10).
Spock can read in a DSSP-format file [5] and take secondary
structure parameters from it. (Spock requires files produced from the
``classic'' pre-1995 version of dssp, or by using DSSP's ``-c'' option.)
The secondary structure parameters are then used in the Secondary
Structure Worm (§6.4.3), and also for the Helix and Sheet
Objects (§6.4.8 and 6.4.9). These parameters
are stored may be accessed in via the r=<helix|sheet|turn|coil>
selection string. In many cases there may be more than one PDB file in
spock's memory, and spock may not know which atoms belong to which PDB
file. Therefore, the ``Open DSSP File'' option prompts and asks to which
atoms the DSSP file should be applied. Usually, the default ``ALL'' is
sufficient. However, if there is more than one PDB file, you should enter
a selection string that will uniquely specify the molecules corresponding
to the DSSP file. For example if molecules 1 and 2 are ribonuclease, and
molecule 3 is lysozyme, and you want to read in the DSSP file for
lysozyme, you should enter the selection string ``m=3''. See §
5.3 for more information on selection strings. Finally, for
an easier way to interface with DSSP see §6.7.8.
Spock does not recognize all of the secondary structure types defined by
DSSP. In particular, all helices are folded into one helix class,
isolated
-bridges are treated as random coil, as are DSSP's
``chiral'' regions indicated by an ``S'' summary structure in the DSSP file.
\
indexphimaps!reading
This option will read in a electrostatic potential map in the format of
grasp ([11]) or DelPhi. This is the same format that spock writes
charge maps in. These maps may then be displayed as contours §
6.4.6. DelPhi/Grasp PhiMap files are limited to 65x65x65
grid sizes. Spock works around this limitation--see Appendix
F.2 for details. Be sure to specify which map slot you wish
to use in the electrostatics menu before reading a phimap, or the map will
go into the current map slot (§6.6.4).
This will read in a DelPhi-format charge file and assign appropriate
charges to the atoms in memory. If a second PDB file is read after
charges are assigned, charges are not assigned to the new file by
default, you have to read the charge file again.
This will read in a DelPhi-format radius file and assign appropriate radii
to the atoms in memory. When a new PDB file is read, the radii are taken
from the internal periodic table (described in §5.2.6),
not the radius file.
This will read in a spock interactions file. An interaction is simply a
connection between two atoms with an associated value, for instance a
distance interaction. The format of this file is described in Appendix
F.1. The interactions will be rendered in the current
interaction style. See §6.4.12 for details. Don't
forget that when you read an interactions file, they won't show up unless
the display menu is set to display them.
This option will read interaction definitions from a MORASS format (.int)
file. All comments above about spock interaction files apply to MORASS
files as well. Some comments about MORASS taken from the README file
accompanying that program are below:
MORASS - Multiple Overhauser Relaxation AnalysiS and Simulation - uses a
full hybrid matrix eigenvalue/eigenvector solution to the Bloch equations
to derive cross-relaxation rates and inter-proton distances. MORASS is
available free for academic use from the research laboratories of
Prof. David Gorenstein. See
http://www.nmr.utmb.edu
for details.
Specify the file name to use for the external objects file. This may be
either a Raster3D file, or a spock objects (.spo) file as described
in Appendix F.3.
Loads the specified XPLOR map into the current density map slot (there
are eight, as described in §6.4.7). The default
directory for XPLOR maps may be set with the SP_XPLOR environment
variable.
This option prompts for a bones file to read in ``o'' format. Bones files
are skeleton files used by crystallographers when building a model.
The Save menu also leads to a sub-menu that requests the type of file to
save. The default directories are determined as described in §
6.1.1.
This option writes out a binary file of the current spock session, saving
nearly all of the current spock state, including (but not limited to):
atoms and surfaces, all colors, the graphics projection and options, atom
and vertex properties and subsets, 2D and 3D contours, and any
electrostatic potential map. Session files are an easy way to save your
work to be resumed later, but they come at a price--session files may be
huge, depending on the amount of memory the current session is taking.
Session files that are not being used should be compressed with gzip
or another compression utility. Compression savings run from 50 to 90
percent, so it's well worth while. Spock recognizes session files by the
extension .sps (spock session), so it's best to name
sessions according to that convention. Of course, as binary files, spock
sessions are hardware-dependent, and not human readable. Only those
individuals who like crashes are advised to attempt to edit session files.
Two notable aspects of spock which are not saved in a session file
are 1) the currently defined macros (the .spmacros file) and 2) any
view files currently defined (.spview0 through .spview9).
These files should be saved separately if you want to use them as well.
Macro files may be saved via the ``Save
Macro file''
option. View files must be copied and saved from the unix command line.
You can save the current view into a file with this option, exactly as for
the View menu (§6.5). Numbered view files (.spview0
through .spview9 are also accessible through the View menu. You
should use the .spv extension for view files. See also the
view= and saveview= commands (§5.2.3).
Instructs spock to write out a PDB file of the currently loaded
molecules. Note that in the file selection box there is a ``PDB Options''
menu, which contains a check-box. If the ``Prompt for Selection'' box is
checked, spock will first prompt the user for a selection string to
determine which atoms should be saved. Otherwise, all atoms are written.
Also, it's possible to apply the current viewing rotation (``Apply
Rotation'') or translation (``Apply Translation'') to the new file. PDB
files created by spock will have HELIX, SHEET and TURN records which
contain the secondary structure information as currently defined. As
noted in the new PDB file itself, the SHEET records are not complete in
that they do not specify the neighbors, the registration or the strand
number. There is, however, enough information included so that if
the file is read back into spock, the secondary structure will be set
properly.
The occupancy and b-factor fields of the PDB file are set from the general
atom properties 1 and 2. If you wish to save a different property in one
of these fields (e.g. charge) the best thing to do is use the ``Swap two
properties'' feature of the Calculate
Properties math menu
§6.6.2, and swap the two properties (e.g. charge and
atom property 1). You may wish to swap them back after the save is
complete, although this is not required.
NOTE: If you've read more than one molecule into spock and then save the
aggregate into a PDB file, there will be a HEADER record written for each
of the original PDB files which contains the molecule id string. This is
so that when the new PDB file is read back into spock, spock (and the
user) will know the source of the original molecules. These extra HEADER
lines are non-standard, and may confuse some other programs which are
(badly) designed to read PDB format files. If this is the case, simply
remove the offending HEADER lines from the new PDB file.
This option overwrites or creates a new .spockrc file which contains
the start-up parameters. The saved information includes the contents of
the control panel (§6.1.8), the contents of the
``Display'' menu, (that is, which objects are currently displayed), the
atom, bond, worm, and CA trace drawing modes, the current worm drawing
parameters, the current colormap, and any currently defined macros.
Be careful with this option if you like to customize spock via the
.spockrc file, because this instruction overwrites any existing file.
The first time spock is invoked, it will create the .spockrc file in
your home directory, including a warning not to make changes below a
certain line. User customization may go above the line and will not be
overwritten by any future use of the Save Preferences File option.
Saves all of the currently defined macros to the indicated file. Macro
files are actually just ordinary command files, and this command copies
the working macro file .spmacros to the named file. See §
6.10 for more information about macros. Note that as macro files
are simply command/history files there is no specific ``Open Macro'' file
option--use ``Open History file'' instead.
Saves all of the instructions executed so far into a file for later
playback. This command actually copies the default history log file
$SP_HISTORY/.spockhist to the specified name. See §7 for
details. Note: the commands to save a history file are placed in
the history log file, but the last set of such commands is eliminated from
the new history file. If you save more than one history file in a
session, some of the history files generated will have save history
commands in them. Be careful, as, this may or may not be what you want.
This option will save in a electrostatic potential map in a format based
on the format of grasp ([11]) and DelPhi. DelPhi/Grasp PhiMap
files are limited to 65x65x65 grid sizes. Spock works around this
limitation--see Appendix F.2 for details.
This will write a DelPhi-format charge based on the current charges. This
file will have one entry for each charged atom, so it might not be the
most compact way to represent the information.
This will write a DelPhi-format radius file based on the currently
assigned radii.
This is option implements the Spock to Molscript [7]
translator (version v1.4 or greater of Molscript is required). Spock will
write a Molscript file that attempts to describe as closely as possible
the view that is on the screen, so that Molscript can render then the
image. You may want to do some final tweaking of the Molscript input file
by hand, but often this is not necessary. Due to differences in spock's
and MolScript's perspective on the world, there is not a one-to-one
translation in all situations. The translation of spock-speak to
Molscript is as follows:
|
Graphical Objects |
|
spock input | Molscript output |
| Atom (any style) | CPK |
|
Line bonds | bonds |
|
Cylinder bonds | ball-and-stick |
|
H-Bonds | dashed lines |
|
CA trace | ca trace |
|
Secondary structure worm
(§6.4.3) | ribbon |
|
| |
|
Parameters |
| atom radius | atomradius |
|
bond radius (from control panel) | stickradius |
|
standard worm height | strandwidth |
|
standard worm widthss | strandthickness |
|
helix worm height | helixwidth |
|
helix worm width | helixthickness |
|
coil radius | coilradius |
|
| |
|
Colors |
| Atom color | atomcolour for atoms |
|
Bond color | linecolour for line bonds, |
|
| atomcolour for ball-and-stick bonds |
|
Label color | linecolour |
|
Worm color | planecolour |
|
Worm shadow color (if enabled) | plane2colour |
Note that for Molscript to produce schematic representations of helices
and sheets, spock must, of course, know about them. Just like for the
secondary structure worm, the exported definitions are taken from the
structure property of the atoms. See the description of secondary
structure worms in §6.4.3 for more details.
In the file selection box for Molscript output there is a pulldown menu
which allows specification of several options to control how the plot
appears.
- Preview: This option specifies that you'd like spock
to run Molscript for you, and call ghostview to view the output.
If you're satisfied with the image you can print directly from
ghostview. This is accomplished via the temporary Molscript file
.spockms. Note that the preview option requires ghostview.
If you don't have it, get it, it's free, or, make a link named
ghostview to your favorite ps previewer. Be sure that the link is
in the search path.
- Print: Runs Molscript and sends the output to the
printer. The print command is specified by the
SP_PRINT_CMD variable (§3).
- File: Saves the current view to a MolScript file, and
requires manually running MolScript to convert it to PostScript or
other output format.
- Landscape Mode: Landscape if checked, portrait
otherwise.
- Stereo Plot: If selected, generates side-by-side
stereo images. The stereo twist and stereo separation values that
spock uses §6.11.3 are exported to Molscript.
However, because of different methods of defining the viewing
projection between spock and Molscript, the stereo separation
parameter is not interpreted exactly the same, so some
experimentation will be required to find the desired stereo
separation value to use with Molscript.
- Frame Plot: Draws a frame if selected.
- One Letter AA: If selected, tells Molscript to use the
one-letter codes for amino acid labels, instead of the full
three-letter abbreviation.
- Cylinder helices: This is a Molscript 2.0 feature. If
this option is checked, helices will be rendered as cylinders,
rather than the schematic backbone trace that's normally used.
This option has no effect if the ``Old version'' toggle is on.
- Old (1.4) version only: This toggles between 1.4 and
2.0 behavior for MolScript. Among the 2.0 enhancements are the
ability to export surfaces, contours and electron density maps.
None of these will be available if you generate a 1.4-only file.
Further, in 2.0, each residue in a backbone worm can have a
different color.
- Export Colors: Generally, the color scheme that spock
uses is not communicated to Molscript, and Molscript uses its own
defaults for coloring. In many cases, you may wish to have
spock's colors used for the Molscript output. Selecting the
options in this sub-menu will accomplish that. Each of the
Background color (spock's color 100), the atom colors, the bond
colors, the worm colors, and the label colors may be individually
selected for export.
- Export Atom Radii: If you have changed the atomic
radii in spock to create smaller atoms, you may wish to select
this option so that spock will tell Molscript what the values
should be for different atoms.
- Export Sizes: If this item is selected, spock will
export the sizes of bonds and worms, taken from spock's bond
radius and worm width parameters, otherwise, Molscript will use
its own defaults.
- Include Coordinates: If this option is selected, spock
will include the PDB file into the Molscript for creating a
``self-contained'' Molscript file, which does not need an external
PDB file. This feature may not be be available on versions of
Molscript prior to 1.4.
- Prompt for selection: This selection only applies if
the ``Include Coordinates'' selection is active. If both are
active, spock prompts for a selection string of atoms to be
included in the Molscript file. Only the selected atoms are
output.
Both the Preview and Print options use ./.spockms as the Molscript
file, so that you do not need to specify a file name if you select either
of those options. Note that the Molscript interface attempts to fill the
printed page to the same extent as the image fills the graphics window.
You will probably want to use the largest magnification that will allow
the image to fit in the screen. Best results are obtained when spock's
window is resized in the horizontal and vertical directions in order to
have as little ``white space'' (``black space?'') as possible.
With creative use of spock's parameters, you can get Molscript to do
almost anything you would like. If, for instance, the ball-and-stick
representations in Molscript are too large, you could 1) decrease
the bond radius (via the Control Panel, §6.1.8), and
decrease the atomic radii of the offending atoms (via the set
radius= command, §5.2.4). Then, select both
``Export Sizes'' and ``Export Radii'', and the ball-and-stick
representations will be scaled down accordingly.
NOTE: It's quite easy to get Molscript to produce Raster3D code instead of
PostScript (specify the -r flag on the MolScript command line). The
Raster3D files so produced are compatible with Raster3D files of the same
scene produced from spock, so it's possible to mix-and-match such files to
use, say, the ribbons rendered via Molscript with the surfaces passed
directly from spock to Raster3D.
Of course, since spock and Molscript have vastly different world views,
there are some inconsistencies between the produced images. Generally,
only displayed objects that are not hidden (colored 0) are output.
However, due to MolScript's selection rules which don't allow mixing of
residue- and atom-based selections, the ball-and-stick output and the bond
output is entirely residue-based. This means that spock looks at the bond
color of the first atom in the residue, and if this atom's bond color is
not 0, the whole residue gets drawn. Similarly, Molscript 1.4 only allows
one color per secondary structural element for backbone worms. Therefore,
spock uses the color of the first residue in the element for the Molscript
output file's color. NEW: This restriction has been removed in
Molscript 2.0. Molscript CA traces will not use ``color by bonds'' or
``color by atoms'' options of spock (cac=b and cac=a,
respectively).
MolScript's bonding algorithm is not as complicated as spock's, and so not
all bonds that are found by spock will be found by Molscript, which simply
connects all atoms that are within a certain distance (bonddistance). If
there is a list of solvent residues named anything other than H2O or HOH
as the last atoms in the PDB file, there may be a 'coil' instruction for
them. Finally, neither the main or the auxiliary clipping planes are
exported to Molscript.
Annotations (§6.4.11) are particularly problematic for spock
to communicate to Molscript. First, Molscript supports only the
Times-Roman font, so if your annotations are not in that font, they will
necessarily look different. Second, point sizes are not consistent
between fonts, so if the annotations may appear larger or smaller in
Molscript than they do in spock. These minor problems may be overcome by
simply using the Times font for spock annotations to be exported to
Molscript. However there are even more serious problems. Although the
origin of a text string in spock is the lower left corner, in Molscript
it's apparently the upper left corner. Therefore, Molscript text
strings are output with the upper left corner in the same relative
position as the lower left corner of the string in spock. Users will have
to manually compensate for this by slightly repositioning the annotations
if they appear offset.
This option will produce an input file for the render module of
Raster3D [2, ], a ray-tracing rendering package for
molecular graphics. The images produced by Raster3D are quite beautiful,
and are recommended for publication quality graphics. Unfortunately,
creating complicated images with just Raster3D is not trivial. Spock
provides an easy-to-use front end to this package which greatly simplifies
the task. Spock requires Raster3D version 2.4b or later for all features
to work properly. If you experience problems with Raster3D export, make
sure that the version of render you're using is at least 2.4b. The
Raster3D package can be obtained free of charge from the authors at
http://www.bmsc.washington.edu/Raster3D/Raster3D.html.
There are several options for the Raster3D output that are selectable via
a menu in the file selection box. There's a preview toggle, which will
save the scene in a file called .spockr3d. Spock then spawns a shell
which will run render on the input file, and invoke $SP_IMGVIEW
(imgview by default) to view it. This means that both render and whatever
you've set $SP_IMGVIEW to must be in your path for preview to work
properly. There's a toggle to select select solid or ``dotted'' H-bonds,
and a toggle to select tell Raster3D if it should create shadows or not.
There's a toggle to use a generated Roman font or to use PostScript fonts
(see below). Finally, there's an option which allows you to set the
thickness of the cylinders used for electon density map representations.
Material properties:
The remainder of the options control for which which (if any) objects
spock's material properties are exported to Raster3D. Raster3D only
understands the shininess, specularity, and opacity material properties.
Note that you must export spock's material properties in order to
render transparent objects. The backface material is also exported for
objects which use it.
External object files (Appendix F.3) are also
translated into R3D format, with certain limitations: 1) Raster3D files
don't support per-vertex triangle colors, so the color for the first
vertex is used for the entire triangle. 2) Raster3D only uses the
shininess, specularity, and opacity material properties. 3) Raster3D
ignores the second radius of cylinders, so cones may not currently be
produced. 4) The LINE object type is rendered as a thin cylinder.
There are two methods for labels and annotations to be exported to
Raster3D. The first method uses render's label object types and
requires you to run labels3d and other programs in that package in
order to render the labels, as described in the Raster3D documentation.
Once you're set up for this, it's fairly painless to use, but getting set
up can be difficult. In this mode, spock will attempt to map the fonts
you've selected (§6.4.11) to an appropriate PostScript font
for Raster3D to use. Only a limited number of font mappings are defined,
but most of the adobe font family is mapped. If spock does not recognize
your font, the output will default to Times-Roman. Appendix §
C contains a list of the font mappings.
The second method is limited to a single font, but the resulting file can
be processed in a single step. This method constructs letters out of
cylinders using a Roman font. The results actually look quite nice, and I
recommend this method. Unfortunately, on most systems there's no X font
which exactly matches the size of the Roman font Raster3D uses, so the
labels may be slightly different sizes in the spock and Raster3D
versions. To enable this option, turn on the ``Generate font'' toggle in
the Raster3D file dialog's menu.
I recommend changing to a high setting of the worm ``Crosswise
Resolution'' parameter before exporting to Raster3D. Experience has shown
that the default value occasionally produces artifacts in the
Raster3D-rendered version. The default value of this parameter is set to
an intermediate value (10) that's appropriate for interactive graphics.
Before exporting to Raster3D, changing this value to 20 will produce
better-looking results. Leaving the value at 20 after exporting the scene
will increase the time it takes to draw each frame, and is probably not
what you want.
NOTE: It's quite easy to get Molscript to produce Raster3D code instead of
PostScript (specify the -r flag on the MolScript command line). The
Raster3D files so produced are compatible with Raster3D files of the same
scene produced from spock, so it's possible to mix-and-match such files to
use, say, the ribbons rendered via Molscript with the surfaces passed
directly from spock to Raster3D.
Neither the main or auxiliary clipping planes are currently exported to
Raster3D, so if you've used them to clip out parts of a scene, the
rendered version will have the entire scene.
This will save an image file in the format specified by the ``Image
Options'' pulldown of the File Selection Box. Currently RGB (SGI), Sun,
GIF, TIFF, PPM, FBM, and PostScript image formats are supported. I don't
recommend JPEG for the most part because of its lossy compression, and
support for JPEG has been removed from spock. The SP_IMAGE
variables sets the initial directory for images. There are several
options for PostScript output, explained in more detail below. Each image
format has its own advantages and disadvantages. Gif's are good for
including on WWW pages . RGB images are heavily supported by
SGI's image tools. TIFF files can be read directly by Adobe Photoshop and
other image-processing software and are a good choice for post processing
images. Finally, PPM files are useful for producing MPEG or QuickTime
movies (§6.11.3).
Note that whenever an image is saved it is first
antialiased to remove the jagged edges caused by the finite pixel size of
the screen. The level of antialiasing applied may be controlled by the
``Graphics
Antialias level'' menu option (§
6.11.2). Setting the antialiasing level to zero
will disable the automatic antialiasing option when images are saved.
The PostScript Options submenu allows a large degree of control over the
final form of the Postscript output. The Paper Size options allow users
to select the desired output paper (or other medium) size. The medium
size is important because it determines the maximum size of the image.
Next, users can select the Orientation, either Portrait or Landscape, and
the color depth, either Full color or Greyscale. Spock's greyscale
algorithm may offer better greyscale conversion than sending a color image
to a greyscale printer. Note that the color setting is ignored for Vector
PostScript images (see below).
The image size options control the width (and by conservation of the image
proportions, the height) of the image on the page. The ``Maximum
possible'' option outputs the largest image possible for the specified
paper size. The ``Screen size'' option is only valid for Vector
PostScript images (described below) and will attempt to make the output
image the nearly same size as it appears on the screen. Finally, the
``Enter width'' option allows you to enter a desired width for the image
(in inches). The actual output image will be the smaller of the page size
or the entered width. Note that spock has a built-in margin for all media
whose width depends on the medium size, because most printers can't print
too close to the edge of the paper.
The final options concern the type of PostScript generated. The
``Scribe/Latex output'' toggle generates a file suitable for including in
a postscript document with no document structuring, titles, or trailing
"showpage". The ``Encapsulated'' toggle controls generation of
Encapsulate PostScript, which is a form suitable for importing into word
processors, and other software. Finally, the ``Vector'' option controls
generation of Vector PostScript, described in detail below.
Spock normally generates a bit-mapped PostScript image, which is a
pixel-level description of the image, and consequently may appear to have
jagged edges if it's scaled up for printing. Vector (or Raster)
PostScript on the other hand, is a description of the image in floating
point coordinates, and is consequently resolution-independent. An image
can be scaled up and will look just as good as the original, just as
increasing the zoom factor in spock does. However, these images may take
much longer to print than bit-mapped PostScript because the scene
has to be re-created out of individual triangles and lines, and the
triangle shading may not be as good as it is on screen. Also, in vector
mode, spock will attempt to map the X fonts you've selected for labels and
annotations (§6.4.11) to an appropriate PostScript font, but
only a limited number of font mappings are defined--mostly just the adobe
font family. If spock does not recognize your font, the output will
default to Times-Roman. Appendix §C contains a list of
the font mappings.
Tips on getting nice-looking PostScript output: Bit-mapped The best
way I've found to get nice bit-mapped PostScript images from spock is to
begin with as large of a window as possible. In the PostScript options
sub-menu, select landscape (since the screen is wider than it is tall),
and make sure the Maximum Possible image size option is checked. Set the
paper size to the desired size. The PostScript output is based on 72 dots
per inch, so make sure that your image pixel size is as big or bigger than
72*the output size you've requested. In no case do you want PostScript to
have to scale up the bitmapped image! Try to make PostScript scale
down the image, which will provide a smoothing effect. Vector
PS Vector PostScript images generally look quite nice, unless for some
reason the shading is off. If the on-screen image doesn't appear to
change when you turn on backface culling (§6.11.3)
then by all means turn it on before saving the image as a Vector PS file,
as it will nearly double the printing speed.
These options will generate VRML files of the scene. VRML, the virtual
reality modeling language, is the standard for 3-D modeling on the WWW.
With an appropriately equipped WWW browser, users can view and manipulate
in 3D the same scene that you generated in spock. The VRML 2.0 version
even has toggles in the output image that allow users to interactively
turn off parts of the structure. I highly recommend running gzip on the
resulting VRML files, as the gzipped files are typically about 70%
smaller than their uncompressed counterparts (they're highly redundant
files). Most VRML viewers will be able to gunzip the files on-the-fly,
resulting in less storage, faster download times and less net bandwidth
wastage.
External objects files (Appendix F.3) are also
translated into VRML, so spock's object description language may be used
as a simple front-end to the VRML language.
Colors taken from spectra are not exported to VRML, because this would
make the resulting files prohibitively large, and VRML files are already
too large by half. Neither the main or auxiliary clipping planes are
currently exported to VRML, so if you've used them to clip out parts of a
scene, the rendered version will have the entire scene. Finally, emaps
are not exported to VRML.
This will write out a spock interactions file
containing all of the currently defined interactions. An interaction is
simply a connection between two atoms with an associated value, for
instance a distance interaction. The format of this file is described in
Appendix F.1.
Saves the map from the current density map (there are eight, as described in
§6.4.7) into the specified file. Spock supports both
ASCII and binary format XPLOR maps, so spock will ask which format you
wish to use. Binary files are smaller and load faster, but they are
platform specific.
This option will delete all atoms, molecules, ... everything. Of course,
it prompts for confirmation first. Same as zap, §
5.2.8.
This option is only applicable during a read from a history file. If
selected, it will suspend reading from the history file until ``Resume''
is selected. This option is the same as the ``pause'' command, see
§5.2.2.
This option resumes
reading from a history file after a ``Pause''. See §7
for information on history files. This option is the same as the ``
resume'' command, see §5.2.2.
This option prompts for the name of a spock command/history file. Spock
will watch this file. If the file's modification time has changed since
the last time spock checked, the file will be read and executed. This
facility allows an external program to control spock. See the file
$SPOCK/bin/webspock for an example.
A novel and exciting feature in spock is the ability to enter into
conferences with colleagues also running spock on their terminals. This
feature is designed to be high-speed, but very low-bandwidth so that it
can work side-by-side with bandwidth-intense Internet-based video and/or
audio conferencing software (such as SGI's InPerson). Alternately, a
phone call may be used to provide an audio link in a conference. User
interaction with either spock session will be passed to the remote session
so that the images on each screen are kept in sync. This can be quite
useful for discussing a crystal structure with a remote colleague. Up to
20 spock sessions on different machines may be linked in this manner.
File transfer is handled seamlessly and transparently when in conference
mode. This means that if you read a file, you can be sure that the same
file is read by the remote system, without any additional user
interaction, so you don't have to worry about file transfer. It should be
pointed out here that any files you read in a conference can be accessed
later by the remote users, so files that you don't want to share shouldn't
be read in a conference.
For those who are interested in how spock's file transfers work, here's a
brief overview. When a local session indicates that a file is to be read,
the remote session (the peer) will look for the equivalent file on
its file system. If a possible matching file is found, the peer computes
a checksum for that file, and sends it back to the local session,
otherwise, the peer sends a nonsense checksum. The local spock session
will then compute a checksum for the local file and compare it to the
peer's checksum. If they match, the local session will signal the peer to
use the peer's copy of the file. If they don't match, the local
session will transfer the file to the peer session on-the-fly, and put up
a message box telling you it's doing so. The transfered file will be
stored in a sub-directory on the remote computer called conf_files.
All the checksum passing is designed 1) to prevent the wrong file from
being read and 2) to minimize network traffic by only sending files when
absolutely necessary.
During the course of a conference, if the remote user has called up a
dialog box (say a file selection box), but not yet entered the
information, the local session will not accept input until that
information has been entered. The cursor will change to a double-headed
arrow to indicate that this is the case, and spock is waiting on
information from the network. This may last for up to 30 seconds. If the
information has not been received by then, the conference connection is
broken and spock is returned to local control.
Finally, the status line will display connection statistics during the
course of a conference. There are three numbers associated with a
connection: TX: the number of commands transmitted; ACK: the
number of commands that the remote computer has acknowledged receiving, and
RX: the number of commands received from the remote computer. For a
multi-party conference, the server maintains connection statistics on each
machine in the conference.
Note that there are a handful of commands that for one reason or another
are not sent to the remote session. Under the File menu, the Pause,
Resume, and Abort playback options are ignored by the remote machine, as
spock has no way of knowing at what point in reading a history file the
other machine is. The File
Print command is also ignored,
as it's not a good idea to allow remote users to control your printers.
Finally, all items in the File
Conference menu itself are
ignored by the remote machine as well. (``End conference'' will, of
course, still terminate the connection.) Under the Graphics menu, the
``Full screen'' option is ignored, as are all stereo options, because the
remote user almost certainly has different stereo viewing preferences than
you do, and there's no reason that the remote user has to be look at the
structure in full-screen mode just because you want to. Finally, because
of the complex synchronization issues that would be involved, it's
impossible to interactively record new macros during a conference.
A note about security: Spock's conferencing mode has been designed with a
trusted-user security model. Although connections may be limited to just
those hosts you allow, once such a connection has been made the remote
user can possibly execute shell commands on your system with the same
access permissions as you have. This makes it a spectacularly bad idea to
run spock as root, but then you knew that. Bear security in mind when
conferencing and be sure that you trust the remote user before granting a
connection. If you decide that you do, you can grant the remote user
permission to execute shell commands, see §
6.1.7 for details. The authors can take no
responsibility for any damage to your system that might result from
using conference mode.
Finally, note that it's even possible to set up conferences between spock
sessions running on different types of hardware and even completely
different operating systems. For instance, we've run conferences between
SGI O2 computers running IRIX, and Intel-based PC's running Linux. This
is possible since all user interaction commands are passed as text
strings, not as binary data. Note, however, that attempting to share view
files, session files, or other types of binary data files between
different computers running on hardware is not likely to succeed. ASCII
files like PDB files and XPLOR maps may be transferred without any trouble.
The menu options are described below:
To initiate a
conference, one of the participants must be set up as a server, and the
other as a client. It makes no real difference which person is client or
server, unless there are firewall constraints to consider. You'll have to
ask your system administrator about this if you don't know. System
administrators should see §3.4 for details.
Whenever a conference is initialized, however, the orientation of the
views on the two machines are synchronized and set to the server's view,
so you may want to consider that when deciding who should play which role.
Choosing this option will first prompt for the machine(s) you wish to
allow to connect. You must specify the full hostname (with domain)
of the machines here. This can be a comma-separated list of machines if
you like. Connections not from machines on the list will be terminated
immediately. Alternately, you can use ``*'' to allow connections from any
machine. Spock will then start a server and begin listening for
connections from the specified machines.
When you start a server, spock will spawn a process called Spm, which is
the simple sockets library portmaster, and then begin listening for
connections. Spock will display a message that it's listening for a
client, and wait up to 30 seconds for a connection to be made. If
successful, spock will display a message indicating the name of the remote
host(s), and that a conference is now in progress.
Since other programs may use Spm, this process is not terminated when
spock exits. If you wish, you may kill Spm using normal system calls
after a spock session if you're sure that it's not being used by other
programs.
The other
participant in a conference is, of course, the client. After you select
this option, you are prompted for the name of the server to which you wish
to connect. You should enter the full hostname of the remote machine,
complete with domain. Spock will then inform you that it's attempting to
contact the server. This process also has a 30 second timeout. When a
connection in made, the server sends some information to synchronize the
views between the two machines, so that the client is brought in
conformance with the server's viewpoint. The information consists of the
server's current viewing projection, color definitions (i.e. what RGB
triple is assigned to color 1, etc), which objects are displayed, and the
colors for single color objects (like CA traces). If the client and
server don't have the same PDB structure(s) loaded, particularly if the
client has a structure loaded and the server does not, this may confuse
the user, as the structure may be translated off screen. If this happens,
simply choose ``Graphics
Reset view'' to re-center the
structure.
This option
will place the conference ``on hold''. While the conference is
suspended, commands are not sent to the remote host(s) and remote
host(s) do not send commands to the local host. Toggling this option
back off will resume communication between hosts. After a conference
has been resumed, there is no guarantee that the local and remote
sessions have the same view (or even the same structure). Therefore
after a hold, either the local or remote user should either ``Send
view'' OR ``Send session'' from the File->Conference menu. If the
structure hasn't changed, ``Send view'' is sufficient, otherwise,
``Send session'' will be necessary.
This will terminate
any conference in progress. The remote machine will be notified when the
connection goes down.
This option
puts up a message indicating if the spock session is acting as a
client or a server, and lists the name of the peer(s) (the remote
machine(s)). If the current session is a server, the message also has
connection statistics for each machine. The statistics (TX, ACK, RX)
are described above.
This option may be
used to set the internet port number which should be used for the
conference. The internet assigned numbers authority (www.iana.org)
has assigned port 2507 for spock. In most cases you should not change
this number. However, if either the local or remote machines is
behind a firewall which blocks traffic on this port, you may wish to
change this port number to a port which is not blocked. Both the
client and the server should use the same port number. The best
solution to dealing with firewalls is to have your system
administrator open port 2507 for TCP and UDP access. Spock should be
the only application accessing this port (and no permanent daemons),
so the security risk is small.
This option allows
one conferee to send the current session to the other conferee, which is
useful at the beginning of a conference if there is a pre-existing session
that one user wants to share with the other. Of course, after the
conference starts, both views are automatically kept in sync.
This option is also
designed for initial synchronization of views at the beginning of a
conference, but the only the much smaller view file is sent over the
wire. This requires both participants to have loaded the same structure.
This option uses the view file .spview9 as a temporary holding space
for the view.
The macro file
.spmacros is not normally sent to the remote machine.
Instead, macros executed on one machine are sent on-the-fly to the remote
machine as a stream of normal commands, so the remote machine doesn't even
``know'' it's executing a macro. If, for some reason, you wish to share
some pre-defined macros with the remote user, you may use this option at
any time to send your current macro definitions to the remote machine. Be
aware that this file will augment the remote user's macro definitions, and
any macros that the remote user has defined with the same names as the
ones you're sending will be overwritten. Recall that due to
synchronization issues it's not possible to interactively define (record)
new macros during a spock session.
This toggle controls a compression method for slower hardware. In
compression mode, not every motion command (e.g. rotations, translations,
zooms, etc.) that's sent over the wire causes a redraw. Instead, these
commands are saved, and redraws are only done every N frames, where N is
the Compression level. Commands that aren't motion commands are executed
normally. Enabling this can cause a significant decrease in lag time for
slower hardware. If the person you're conferring with keeps getting
``Waiting for remote to catch up...'' messages, you should definitely turn
on compression, or increase the compression level.
This option toggles
the conference mouse mode. In this mode, if the left mouse button is held
down, cursor movements on one machine are transmitted to the other
machine. This allows conferees to use the mouse to indicate particular
regions of the structure. If you wish to use the normal left mouse button
function (rotation), you can either 1) turn Conference mouse off again or
2) hold down the shift, alt or control keys before pressing the button.
Note that only mouse movements inside the main graphics window are
transmitted. Note that the since spock doesn't care what the window
size (or even the screen resolution) of the remote session is mouse
positions are not passed as absolute or relative pixel coordinates.
Instead they are passed as fractions of the graphics window size. In
order for these fractions to indicate roughly the same area on each
screen, each graphics window should be as nearly square as possible. If
this convention is not obeyed, the mouse positions you send may indicate a
totally different portion of the structure to the remote user.
This toggle indicates if spock should print each remote user command as it
is received. This may be helpful for learning spock if an experienced
user is in a conference with a less experienced one, or may simply be
informative.
This
toggle controls if commands should be passed to the shell during
conference mode. This is a security feature designed to prevent
accidental or intentional damage to your file system by the remote user.
For instance, the remote user could issue the command ``|rm -rf /''
which would ordinarily remove all the files in your file system to which
you have write permission. If allow shell commands is off, however, no
commands entered from the command line are passed to the shell. Since
it's possible to be reading a history file that was transfered from the
remote machine as well, all shell commands are prevented during a
conference, even those from the local user. If you trust the remote user,
you may wish to turn this option on to allow more functionality.
This option pops up the control panel, from which you can specify the
radii to be used for the cylinders which represent bonds, worms, helices,
sheets and interactions. You can also specify the resolution for Atoms
spheres. The maximum value is hardware-dependent, but 10 is usually quite
sufficient for presentation quality spheres. For general work, the
default of 5 is fine. Finally, you can set the mouse sensitivity here as
well. Smaller sensitivity values mean you'll have to move the mouse more
to accomplish the same motion. This is most useful for detail work. If
you have a dial box (§4.4), it's also affected by this
parameter, as is the fake dial box (§6.11.5). You can also
set the current frame if you've opened an Amber or XMOL trajectory file (§
6.7.9).
This menu allows the user to set a few personal preferences. The first
options control where the output of the list command goes. This
output can either go to the default text output window, or a separate
pop-up window. This menu also allows the user to specify the autosave
frequency. By default spock saves a session file in the current working
directory every 3 minutes called .spautosave.sps. This file may be
used to recover from a system crash or a power failure. You can change
the save rate or disable autosaves from the this menu.
This option will send a PostScript rendering of the current image to the
printer. The command used to send the image to the printer is specified
in the SP_PRINT_CMD environment variable, as described in §
3. There is no ``Page setup'' option in spock. Instead, all
printing options are taken from the PostScript options menu in the Save
Image dialog box, §6.1.2. See that section for hints on
getting good-looking PostScript output.
This option prompts for confirmation
before quitting spock. This is the same as the quit command,
§5.2.8.

Next: Edit
Up: Menus
Previous: Menus
Jon Christopher
Tue Sep 14 16:44:48 CDT 1999