Db_a2r_avera(age) 080218
Db_a2r_avera <mol> <atom property> <new residue property>

This command generates a residue property from the average of an atom property on a per residue basis. For example, temperature factors are often generated on a per atom basis while sometimes it would be nice to see a graph of the average B-factors calculated on a per residue basis.

O > Db_a2r_avera
Heap> Convert an atom-based property to a residue one
Heap> Molecule [1OGM ]:
Heap> Atom-based ODB 1ogm_atom_[B]:
Heap> Residue-based ODB 1ogm_residue_[B]:


Db_and (080218)
db_and <destination> <first> <second>

This command carries out a logical AND operation between two properties of logical variables (0=off, 1=on). The logical values would normally be generated with the select_property command. The result of the operation could be used for use with the Paint_property command or to make objects.

In the following example, I select all solvents with an electron count > 5, and with B <10. After making the AND operation, I create an object to show the results.

O > Select_off
Sel> What molecule [1OGM ]:
Sel> Residue range [all molecule]:
O > Select_prop
Sel> Property? [atom_name]: res_ele
Sel> Operator (< > <= >= ^= [=]): >
Sel> Value? []: 5
Sel> [On]/off:
O > Copy_db first 1ogm_atom_select

O > Select_off ;;
O > Select_prop res_b < 10. on

O > Db_and
Heap> A = B and C
Heap> A (destination) ODB : 1ogm_atom_select
Heap> B (first) ODB : first
Heap> C (second) ODB : 1ogm_atom_select

O > Select_visib
O > z ; end


Db_or (080218)
db_or <destination> <first> <second>

This command carries out a logical OR operation between two properties of logical variables (0=off, 1=on). The logical values would normally be generated with the select_property command. The result of the operation could be used for use with the Paint_property command or to make objects.

In the following example, I select all solvents with an electron count > 5, or with B <10. After making the OR operation, I create an object to show the results.

O > Select_off
Sel> What molecule [1OGM ]:
Sel> Residue range [all molecule]:
O > Select_prop
Sel> Property? [atom_name]: res_ele
Sel> Operator (< > <= >= ^= [=]): >
Sel> Value? []: 5
Sel> [On]/off:
O > Copy_db first 1ogm_atom_select

O > Select_off ;;
O > Select_prop res_b < 10. on

O > Db_or
Heap> A = B or C
Heap> A (destination) ODB : 1ogm_atom_select
Heap> B (first) ODB : first
Heap> C (second) ODB : 1ogm_atom_select

O > Select_visib
O > z ; end


Db_create

db_create <name> <size> <type>

Create a new data block. The user must specify the name, the size of the block and its allowed type (I,R or C). This command could be used to create new residue or atomic data blocks, for example. It is up to the user to ensure that the block is of the correct size.

Db_delete

db_delete <param>

Delete one or more existing data block. Wild card characters (*) are allowed. The user is prompted before each delete is made. Db_kill is a related command that deletes without confirmation.


Db_kill

db_kill <param>

Delete one or more existing data block. Wild card characters (*) are allowed. The user is not prompted before each delete is made. Db_delete is a related command that deletes with a prompt confirmation.

Db_set_atom

For the current molecule, set an atomic data block of a particular atom (e.g. CA) in a zone to a certain value. In the following example, for, example, the B-factor of all CA atom sin the zone A1 to A10 are set to the value 20.0
 
Heap> d_s_a
Heap> Full name of data block: A_atom_b
Heap> It is of type R and has 1054 entries
Heap> Start and end residues in zone ([all residues]): a1 a10
Heap> Atom name [CA] :
Heap> Value (must match param block) : 20.
Heap> There were 10 marked atoms
Heap>


Db_set_data

Set consecutive locations in a data block to a particular value. In the following example, all values of the B-factor datablock of molecule A are set to the value 22.0
 
Heap> d_s_d
Heap> Full name of data block: a_atom_b
Heap> It is of type R and has 1054 entries
Heap> Start and end entries [1 1054 ]:
Heap> Changing entries 1 to 1054 of data block a_atom_b
Heap> Enter value (must be type R): 22.
Heap>
 
Db_set_group
 
Set the contents of a particular datablock to some value. The entries are determined by identifying an atom, and then all atoms that are connected to it are affected. In the following example, the tempertature factor datablock is specified, and the value that will be set is 10.0 The user must then identify an atom.All atoms connected to this atom, will then have their B-factors set to 10.0
 
Heap> d_s_g
Heap> What datablock : atom_b
Heap> Set to value: 10.
Heap>
 
Db_set_zone

Set a datablock for all atoms in a zone to a value. In the following example, the B-factor of atoms of molecule A, in the zone a30 to a50 are set to 50.0
 
Heap> d_s_z
Heap> Full name of data block:A_atom_b
Heap> It is of type R and has 1054 entries
Heap> Start and end residues in zone ([all residues]): a30 a50
Heap> Value (must match param block) : 50.
Heap>
 
Db_statistics
 
db_statistics <DB name>
 
Provide simple statistics for the values in a spcified datablock. For example, the temperature factors of molecule NA are specified below
 
Heap> d_sta
Heap> Name of datablock: na_atom_b
Heap> Minimum and maximum values: 6.4200 80.5300
Heap> Mean and standard deviation: 34.3379 13.3626
Heap>

Db_table_residue

db_table <residue property name> <property type> <table values>
 
Make a new residue property from a table of residue properties.

For example, if we wanted to paint according to the charges on residues, we would need to load the residue table containing the charges into the database, creating a new property called charge in the process
 
Heap> db_ta
Heap> This file must contain a residue name and value.
Heap> The value must match the param block type.
Heap> e.g. in the following it is character*6
Heap> ALA Small
Heap> VAL Medium
Heap> PHE Big
Heap> Name of residue data block:A_residue_charge
Heap> Type of elements (C,[I],R): i
Heap> File name of residue table: table_charge.txt
 
The new property could then be used to colour objects. For example,

paint_case residue_charge 3 -1 0 1 red white blue z ; end
 
The file called table_charge.txt specified above could contain the following:

ARG 1
ASN 0
ASP -1
CYS 0
CYH 0
GLU -1
GLN 0
GLY 0
HIS 1
ILE 0
LEU 0
LYS 1
MET 0
PHE 0
PRO 0
SER 0
THR 0
TYR 0
TRP 0
VAL 0
SOL 0
 

Decor Overview (101202)
The Decor commands are used during the map interpretation stage of model building. A more detailed overview can be found in the review by T.A. Jones (Acta Cryst (2004) D60, 2115-2125).
O works uses the following representations of a molecule during the map interpretation stage.


The skeleton is useful to sketch how a macromolecule folds in space. The TRACE, on the other hand, provides a more detailed representation of the molecule, and has local directionality. It can be built more or less automatically with a subset of the Decor commands. The user is able to guide this process by constructing secondary structure elements interactively with the SST commands, which can be incorporated in the automatic step. The actual molecule when built, has directionality and sequence placement. The step in going from the TRACE to a molecule (or part of a molecule) with the sequence assigned, I call decoration. The Decor commands assist in this step.

Some Decor commands are specific for proteins, while others will work with protein or RNA molecules.

Some Decor commands allow you to control how one modifies a particular hypothesis for how the actual sequence should be threaded onto the poly-alanine TRACE molecule, others allow you to create the necessary data structures to make the decoration. A new set of commands available from Ov13, greatly simplify working with this system, allowing the user to rapidly go from a connected skeleton to a poly-alanine TRACE with a suggestion for how the sequence is threaded.

These commands are most easily used from the skeleton master menu.

The overview of the process, therefore is:





Decor_easy (101020)
Decor_easy <ID start and end point in skeleton> <Yes/No>

This command does everything needed to produce a decorated TRACE molecule, leaving Decor_slider active. The results are stashed in the Decor system with the name 'easy' so that the user can return to them at a later date. This is a new implementation where the TRACE making step is not just faster, but also better.

When started, the command checks to see what is in the ODB and issues warnings as are appropriate. For example, in this case the molecule currently selected for building (with the Build_molecule command) has been accidently deleted:

O > de_easy   
New> ******************** Molecule to be built is: M1
New> Molecule to be built does not exist
New> Only you know the molecule to be built
New> Prepare the ODB entries from the sequence with Sam_init
New> Then define it with the Build_mol command
New> Forced to abort.

If some of the necessary trace-related ODB entries are missing, the user gets warned and O tries to read them in:

O > dec_easy
New> ******************** Molecule to be built is: P2
New> ALPH5 molecule does not exist
New> O will attempt to read in the necessary files
something set in the TRACE
As4> ******************** Prepare TRACE molecule
Heap>  trace_2ry.odb contains SST and related molecules ....


Note that if the trace.odb and/or trace_2ry.odb files are not where they should be, the program can still fail.

The user is first prompted to indicate the start position and then the end position on a skeleton. The two points must be connected, with just a single, unique path from the first to the second point. The first identified point will indicate the N-terminal region in the poly-alanine TRACE molecule that eventually gets built. The order is, therefore, critical! After making the second identification, the user gets to see what the track through the skeleton looks like and has a chance to cancel the command (use Clear_flag). A new skeleton called KAT is actually made that contains the connected atoms between the pair of ID’ed atoms.
If the user has already started to built SSTs in the TRACE, he/she is prompted to see if they should be used or not (activate the YES or NO commands, as is appropriate).
O then passes through a number of distinct steps:
1/ Builds a poly-alanine TRACE that follows the trail of skeleton atoms. This is, in turn, a multi step process whose exact algorithm is described elsewhere. One step involves the building of secondary structure, and a second step involves building the loops between consecutive structures. The latter makes use of skeleton branch points to identify both side-chain branches at CA atoms, as well as carbonyl oxygens, if present. The KAT skeleton atoms are assigned classes and therefore appear in different colours to indicate the location of loops, helical and strand segments (yellow, cyan and green by default, with skeleton codes 1, 3, and 4 respectively.
2/ Real-space density optimization of the built TRACE in the currently defined map.
3/ Goodness-of-fit evaluation of each side-chain rotamer, at each residue in the TRACE.
4/ Yasspa runs to identify helical and strands in the TRACE
4/ Decor_slider with control entry .TRACE_GUESS_EASY that uses just secondary structure segments for the threading.
After a pause, therefore, the user will see a CA representation of the TRACE molecule that is coloured with default yellow, red and green (loop, helix, strand), decorated at the secondary structure elements with the suggested threaded sequence. Any position in the TRACE that scores well for a TRP residue is indicated (in cyan). Any disagreement between the threading length and TRACE length within loops is indicated in the usual way by text stating the size of the discrepancy (in red). My algorithm allows indels that are less or equal 2 residues in these loop regions, so text values in the range -2 to +2 may appear. If the value is positive, the threaded loop is longer than the TRACE loop, if it is negative the thread is of shorter length.
Once Decor_slider is active, the user is free to modify the threading by judicious use of the Decor_fix command.
Here is an example of a Decor_easy run on the P2 myelin averaged map where the output in the GOF evaluation has been reduced- there is one goodness-of-fit line at each residue:

O > dec_easy
New> ******************** Molecule to be built is: P2
As4> ******************** Prepare TRACE molecule
New> Backup made of trace_residue_trace
New> A TRACE will be generated.
New> Number of branches 63
New> Peptides per branch 2.12767
New> Low branching frequency.
New> All C-branches are re-assigned as CAs
New> Build N/C- & loops between TRACE elements using branch points.
New> There are 11 TRACE elements to connect.
New> Build loops between TRACE elements using branch points.
New> Build C-terminus of the TRACE using branch points.
New> Build N-terminus of the TRACE using branch points.
As4> ******************** RSR the TRACE
New> Map used is TAJ
1 128 3
As4> ******************** Evaluate fit to each residue in TRACE
Slid> In context of residues : Slid> Molecule being build [P2 ]: Slid> Map used is TAJ
TRACE ALA SER VAL LEU ASP GLU ILE MET PHE TRP HIS LYS ARG PRO
1 0.78 0.73 0.69 0.64 0.59 0.60 0.69 0.50 0.57 0.50 0.60 0.62 0.53 0.78
2 0.76 0.72 0.66 0.61 0.57 0.51 0.61 0.48 0.49 0.43 0.49 0.56 0.47 0.74
3 0.59 0.68 0.63 0.71 0.75 0.77 0.72 0.73 0.74 0.68 0.82 0.73 0.63 0.66
4 0.70 0.75 0.70 0.73 0.71 0.66 0.71 0.57 0.62 0.53 0.62 0.66 0.56 0.62
5 0.68 0.57 0.56 0.52 0.46 0.44 0.52 0.41 0.42 0.35 0.42 0.48 0.41 0.60
6 0.83 0.83 0.79 0.73 0.65 0.61 0.73 0.57 0.59 0.48 0.56 0.67 0.57 0.76
7 0.44 0.45 0.42 0.52 0.51 0.65 0.50 0.70 0.74 0.72 0.75 0.69 0.70 0.39
8 0.77 0.64 0.64 0.60 0.53 0.50 0.60 0.47 0.48 0.40 0.48 0.54 0.46 0.67
....
128 0.75 0.64 0.63 0.57 0.51 0.48 0.58 0.45 0.46 0.39 0.46 0.52 0.44 0.64
129 0.60 0.50 0.49 0.45 0.40 0.37 0.45 0.35 0.36 0.30 0.36 0.41 0.35 0.48
Slid> g31
Slid> Done
As4> ******************** Decorate the TRACE
Heap> Deleted TRACE_RESIDUE_2RY_STRUC
Util> Template size : 5 residues.
Util> There were 14
Util> Template size : 5 residues.
Util> There were 79
stretch 6 8
stretch 11 13
stretch 15 22
abutting 2ry structures
stretch 23 25
stretch 29 34
abutting 2ry structures
stretch 35 44
stretch 47 54
stretch 57 63
stretch 68 73
stretch 81 85
stretch 88 95
stretch 98 107
stretch 110 117
stretch 120 127
Number of stretches 14
Optimal path 7 11 16 24 28 36 48 58 69 83 90 100 112 122
As4> ******************** Decor guess is called EASY

Here is the contents of the ODB that is controlling the threading:
....
As4> ******************** Decorate the TRACE
Optimal path 7 11 16 24 28 36 48 58 69 83 90 100 112 122
O > dir *easy*
Heap> @DECOR_EASY T W 710
Heap> .TRACE_GUESS_EASY T W 994
O > wr .TRACE_GUESS_EASY ;;
.TRACE_GUESS_EASY T 14 70
stretch 6 8
stretch 11 13
stretch 15 22
stretch 23 25
stretch 29 34
stretch 35 44
stretch 47 54
stretch 57 63
stretch 68 73
stretch 81 85
stretch 88 95
stretch 98 107
stretch 110 117
stretch 120 127

To Decor_slider option, this entry is simply known as easy so if you Clear_flag, you can get back to the thread very easily:
O > dec_slid
New> Define a .Trace_guess_* DB [1]: easy
New> Molecule getting built [P2]:
Optimal path 7 11 16 24 28 36 48 58 69 83 90 100 112 122

The command can take a while to run but is of course dependent on the performance of your computer; the P2 myelin molecule (~130 residues) needs 135 seconds on my Apple MacBook Air (lovely bur slow,1.8 GHz Intel Core Duo processor). Most of the time is spent doing the RSR-fit and the GoF calculation, The new TRACE generating algorithm is fast.


Decor_step_1 (101021)
Decor_easy <ID start and end point in skeleton> <Yes/No>
This command is a subset of Decor_easy, carrying out the first steps that allow the user to generate a poly-alanine TRACE from a pair of connected skeleton atoms. The TRACE appears with YASSPA colour coding, but is not RSR-fitted to the density. For details, see the Decor_easy description above.


Decor_step_2 (101021)
Decor_easy <ID start and end point in skeleton> <Yes/No>
This command is a subset of Decor_easy, carrying out the latter steps that allow the user to use a poly-alanine TRACE as the framework for evaluating sequence matching goodness-of-fit indicators, and controlling how the sequence threads onto the TRACE. The TRACE appears with YASSPA colour coding, and is RSR-fitted to the density before evaluating the GOF. For details, see the Decor_easy description above.


Decor_fast (101202)
Decor_fast <ID start and end point in skeleton> <Yes/No>

This command is identical to Decor_easy except the intermediate TRACE molecule does not undergo a real-space refinement step, and there is no calculation of the goodness-of-fit indicators for how well the different amino acids can be fitted to each residue in the TRACE. The user may prefer to use this command when working at low resolution or with bad maps, or in other situations where the density optimization step is unlikely to improve the TRACE. Under such circumstances, the user may prefer to build secondary structure elements (especially helices) with the interactive SST commands and incorporate them ‘as is’.

Because no use is made of the electron density, the threading shown at the end of the process is almost certainly wrong. In fact, the first 'not built' residue in the sequence is placed at the first residue in the TRACE, and so on until the end of the TRACE.

In the following example, skeleton atoms 40 and 157 are connected and identified in turn to specify the start and end points for Decor_fast.

A TRACE of 129 residues is built, with the secondary structure elements indicated:

Residue 1 in the sequence is equivalenced to residue 1 of the TRACE. The sixth residue in the TRACE corresponds to the first residue of the first strand, and appears as the suggested thread A6, which is a glycine residue. This continues throughout the TRACE, until we come to the last residue of the last strand at residue 127 in the TRACE, which is threaded to A127, an isoleucine in the P2 sequence:

The threading must then be corrected by using the Decor_fix command.



Decor_fix (050803)

decor_fix <ID atom in a TRACE stretch>

This command is used when the Decor_slider command is active to force a change in the current path. The user first sets the position in the sequence where a particular residue in the TRACE has to be decorated. A new pass through the dynamic programming algorithm in Decor_slider is then made, to produce a new thread of the sequence onto the TRACE. The is prevented from making a fix that would force a segment (or a part) outide the sequence of the molecule getting built.

Decor_fix is used to force the threading to the result wanted by the user. The application of this command, however, needs some careful thought. For example, consider what happens the first time a Decor_fix is made to a stretch. If the user wants to force a path that is different from the thread, the decoration could change at both the N- and C-terminus of the residue where the fix is made. In this situation, if the user had been happy with residues to the N-terminal end of the fix, the threading could have changed. Now suppose the user makes the first fix at a point where he/she is happy with the threading to the N-terminus with respect to the fix. Any additional fixes that may get made to the C-terminus of the first fix, will no longer affect the threading to the N-terminus of the first fix. My strategy, therefore, is to use Decor_fix to force a change in the threading but to also clamp a particular threading so that later changes do not have a deleterious affect.


When a stretch is fixed, the threaded sequence that is mapped to the TRACE is coloured white .

In this threading (Decor_slider is active), there is a discrepancy between the TRACE and how the sequence decorates it. Residue 7 in TRACE is associated with residue 9 in the sequence, while 10 is associated with 11. This is not possible, as indicated by '*-1*', one residue too few in the sequence, while there is one residue too many in the gap between 13S and 16F (indicated by '*1*').
The user decides that residue 10 in TRACE is actually residue 12 in the sequence. The Sequence slider pull-down has been set to indicate this, and then Decor_fix was activated to produce a new threading. Fixed stretches have the sequence painted white.




Decor_free (050808)

decor_free <ID atom in a TRACE stretch>

This command is used when the Decor_slider command is active to release a stretch in the TRACE that has been previously fixed to a particular residue in the sequence. A new pass through the dynamic programming algorithm in Decor_slider is then made, to produce a new thread of the sequence onto the TRACE.

When a stretch is fixed, the threaded sequence mapped to the TRACE is coloured white. Therefore, if the stretch was prevously fixed, the threading text will change from white to green


Decor_guess (050805)

Decor_guess <framework molecule> <context zone> <molecule being built>

This is a new version of the Zou & Jones (1996) system for determining a quantitative estimate for where we are in the sequence. During the map interpretation stage, the framework molecule would be TRACE. The context zone usually corresponds to a contiguous zone in the TRACE molecule. For each residue in the TRACE, we evaluate the fit of different residue types. The score is a correlation coefficient of the best fitting rotamer to the density. For reasons of speed, the rotamers are first fitted to the electron density using the rapid scoring funtion of Build_ed_rot. This makes use of a mask generated from the current electron density level in the Denisty slider of the masp being used. This mask essentially delimts the density for the side-chain. The correlation coefficient is then made between this extracted density and the density of the side-chain calculated from the atomoc coordinates of the best fitting rotamer. For the latter, side-chain atoms are modelled as Gaussians, using Ao and c parameters of 0.9 & 1.04 (see RSR_Setup command), integration radius of 3 pixels, and overall B-factor of 20Å2.
It is critical to set a reasonable value in the density slider; in the examples on the P2 averaged map, I used a value of 1 sigma.

O > decor_gues
Slid> Framework Molecule [TRACE]:
Slid> In context of residues : 1 122
Slid> Molecule being build [TRACE ]: p2
Slid> Map used is AV
TRACE ALA SER VAL LEU ASP GLU ILE MET PHE TRP HIS LYS ARG PRO
1 0.48 0.57 0.65 0.56 0.51 0.51 0.64 0.41 0.43 0.43 0.49 0.47 0.42 0.56
2 0.43 0.62 0.58 0.60 0.72 0.59 0.64 0.55 0.64 0.54 0.62 0.63 0.55 0.61
3 0.47 0.42 0.42 0.38 0.43 0.42 0.39 0.40 0.32 0.31 0.40 0.36 0.36 0.45
4 0.42 0.37 0.36 0.34 0.31 0.38 0.34 0.30 0.29 0.31 0.30 0.35 0.40 0.35
5 0.70 0.67 0.70 0.63 0.61 0.55 0.66 0.52 0.53 0.44 0.53 0.58 0.51 0.70
6 0.34 0.42 0.39 0.48 0.48 0.64 0.48 0.55 0.72 0.75 0.74 0.68 0.60 0.38
7 0.65 0.58 0.55 0.50 0.49 0.45 0.52 0.43 0.44 0.38 0.44 0.48 0.42 0.53
8 0.54 0.64 0.60 0.61 0.63 0.57 0.61 0.52 0.53 0.45 0.53 0.57 0.50 0.44
9 0.73 0.70 0.70 0.63 0.59 0.55 0.67 0.51 0.53 0.46 0.53 0.58 0.51 0.64
10 0.67 0.61 0.62 0.55 0.53 0.48 0.57 0.45 0.46 0.40 0.46 0.52 0.45 0.59
11 0.53 0.55 0.51 0.48 0.49 0.43 0.49 0.39 0.41 0.35 0.41 0.45 0.39 0.49
12 0.52 0.45 0.48 0.42 0.38 0.36 0.45 0.34 0.35 0.30 0.35 0.39 0.34 0.49
13 0.59 0.63 0.67 0.68 0.71 0.64 0.68 0.67 0.58 0.52 0.57 0.63 0.55 0.58
14 0.44 0.54 0.47 0.54 0.63 0.64 0.58 0.64 0.75 0.69 0.71 0.66 0.67 0.38
...
117 0.61 0.61 0.59 0.54 0.53 0.47 0.56 0.45 0.47 0.39 0.47 0.53 0.44 0.52
118 0.30 0.29 0.30 0.32 0.31 0.38 0.36 0.38 0.38 0.43 0.40 0.47 0.50 0.30
119 0.50 0.48 0.50 0.44 0.44 0.53 0.47 0.47 0.42 0.40 0.38 0.43 0.37 0.35
120 0.25 0.24 0.22 0.20 0.24 0.33 0.22 0.24 0.18 0.34 0.18 0.37 0.42 0.24
121 0.58 0.59 0.55 0.59 0.57 0.60 0.55 0.52 0.56 0.53 0.58 0.56 0.49 0.55
122 0.66 0.64 0.61 0.62 0.60 0.59 0.61 0.57 0.56 0.45 0.57 0.58 0.50 0.69
Slid> g1
Slid> Done…

A new entry is made in the ODB associated with a residue property of the TRACE molecule, TRACE_RESIDUE_GOF to contain the goodness of fit indicators.

Large aromatic side-chains such as tryptophans are frequently found buried in the hydrophobic core of a protein and have very well defined electron density. Together with their low relative frequency in protein sequences, this means that TRP residues can be beacons in determining where we are in the sequence. Notice the high scores for TRP at TRACE residues 6 and 14, for example. Decor_guess, therefore, creates a special residue-based ODB showing the score of TRP at each point in the TRACE. If this ODB, TRACE_RESIDUE_TRP, is plotted in the O Graph pull-down, the user is able to see where potential TRP residues (or other large aromatic residues) are located in the electron density.

TRP goodness-of-fits for TRACE 1 to 122 . The highest scoring residue is number 6 in the TRACE and is indeed a tryptophan, The next highest is a PHE at residue 14 in the TRACE
Fourteen different amino-acids have been positioned at each residue in the TRACE. These have been specified in an entry .guess_matrix in the user's database. This together with a description pof each residue must be loaded into the database before running Decor_guess. Default entries with a 14 amino-acids guess-matrix are part of the distribution startup.odb from Ov10, but can be loaded separately:

O > read sc.odb
O > read guess_matrix_2.odb

Here is the entry contained in the file guess_matrix_2.odb that is distributed:

.% cat guess_matrix_2.odb
! with PRO
.GUESS_MATRIX T 21 72
ALA SER VAL LEU ASP GLU ILE MET PHE TRP HIS LYS ARG PRO
ALA 10 0 0 0 0 0 0 0 0 0 0 0 0 0
CYH 0 10 0 0 0 0 0 0 0 0 0 0 0 0
ASP 0 0 0 0 10 0 0 0 0 0 0 0 0 0
GLU 0 0 0 0 0 10 0 0 0 0 0 0 0 0
PHE 0 0 0 0 0 0 0 0 10 0 0 0 0 0
GLY 10 0 0 0 0 0 0 0 0 0 0 0 0 0
HIS 0 0 0 0 0 0 0 0 0 0 10 0 0 0
ILE 0 0 0 0 0 0 10 0 0 0 0 0 0 0
LYS 0 0 0 0 0 0 0 0 0 0 0 10 0 0
LEU 0 0 0 10 0 0 0 0 0 0 0 0 0 0
MET 0 0 0 0 0 0 0 10 0 0 0 0 0 0
ASN 0 0 0 0 10 0 0 0 0 0 0 0 0 0
PRO 0 0 0 0 0 0 0 0 0 0 0 0 0 10
GLN 0 0 0 0 0 10 0 0 0 0 0 0 0 0
ARG 0 0 0 0 0 0 0 0 0 0 0 0 10 0
SER 0 10 0 0 0 0 0 0 0 0 0 0 0 0
THR 0 0 10 0 0 0 0 0 0 0 0 0 0 0
VAL 0 0 10 0 0 0 0 0 0 0 0 0 0 0
TRP 0 0 0 0 0 0 0 0 0 10 0 0 0 0
TYR 0 0 0 0 0 0 0 0 10 0 0 0 0 0
 
File guess_matrix_1.odb lacks the PRO, but is otherwise identical. It is a scoring matrix too, defining how the scores for the missing residues are to be generated. For example, the score for a TYR residue is the same as for a PHE residue, an ASN like an ASP, etc.

The framework molecule should always be the TRACE, but is not enforced at this stage.

The ODB entries for the molecule being built must exist at this stage, These can be generated from the sequence with Sam_init or Build_init .

Decor_show (050809)
Decor_show <framework_molecule> <context zone> <residue>

This command allows one to see how different side-chains can be fitted to particular residues in a structural framework. The scoring method is the same as used by Decor_guess.

O > dec_sho
Slid> Molecule [TRACE]:
Slid> In context of residues : 5 7
Slid> Residue: 6
Slid>
TRACE ALA SER VAL LEU ASP GLU ILE MET PHE TRP HIS LYS ARG PRO
6 0.34 0.42 0.39 0.48 0.48 0.64 0.48 0.55 0.72 0.75 0.74 0.68 0.60 0.38
 
The scores refer to the fits of the various residue types defined in the .guess_matrix DB (see Decor_guess above). Although all residues defined in .guess_matrix are used in the calculation, the 3D window shows only the the result of activating the macro @on_autofit As distrubted, this macro contains:

@on_autofit t 7 50
mol scarg z ; end
mol scphe z ; end
mol scleu z ; end
mol scval z ; end
mol scser z ; end
mol scala z ; end

 
This is the residue being evluated in the above calculation. It is a TRP.
Here is an ARG
In this case, the residue should actually be a MET.
This command can be very helpful to decide what sorts of resides may be present at points in the TRACE. This information can then be used in Decor_slider to assist in the decoration process (see the description for the TYPE keyword).

 
Decor_slider (101014)

decor_slider <guess> <molecule being built>

This command uses a dynamic programming algorithm (DPA) to decorate a TRACE with the sequence. If Decor_guess has been used to generate the goodness-of-fit indicators for how each kind of amino-acid fits at each position in the TRACE, these indicators are used as the basis for the threading. If the user omits this step, the command can still be used but the threading will not have made any use of the electron density. The user is always able to control the threading by judicious use of the Decor_fix command.

Usually, a user will have generated input to this function via Decor_easy, Decor_yasspa or a previous run of Decor_slider. This input takes the form of ODB entries with names starting .trace_guess_:

O > dir .trace_guess*
Heap> .TRACE_GUESS_2 T W 355
Heap> .TRACE_GUESS_3 T W 213
Heap> .TRACE_GUESS_4 T W 284
Heap> .TRACE_GUESS_1A T W 1136
Heap> .TRACE_GUESS_1AA T W 1136
Heap> .TRACE_GUESS_1 T W 852
Heap> .TRACE_GUESS_TYPE T W 923
Heap> .TRACE_GUESS_EXCLUD T W 497

The extension given to the guess must be less than 6 characters in length.
The guess .trace_guess_1 was generated by Decor_yasspa using residues 1-122 in the TRACE molecule described in Decor_guess above:

O > wr .TRACE_GUESS_1 ;;
.TRACE_GUESS_1 T 12 70
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 42
stretch 46 51
stretch 55 62
stretch 68 71
stretch 77 81
stretch 87 92
stretch 95 103
stretch 107 112
stretch 115 121

The threading of the TRACE to the density is only evaluated in 12 stretches in the above example. Initially these correspond to the secondary structure elements generated by Decor_YASSPA. The loops between are only used to constrain the size of the allowed breaks in the threading to the TRACE. Such breaks are only allowed in these loops, and have maximum allowed deviations of +/- 2 residues. When they occur, such deviations are indicated. Here is the output from using Decor_slider and the threading mapped onto the TRACE:

O > dec_sl
New> Define a .Trace_guess_* DB [1]: 1
New> Molecule getting built [P2]:
12 131 131 12
Optimal path 7 11 16 27 49 58 71 80 91 100 113 123




The decoration is essentially correct. The short, second stretch is out of register by one residue, as is the first stretch in the 'back' sheet (containing the decoration 80T->84 V in the above).
As well as the sequence decoration, indications are shown where the TRACE and the threaded sequence differ in length. The text '*-1*' between the first two stretches indicates that the length of the TRACE between the stretches differs from the length of the threaded sequence. In this case, the TRACE has 2 residues in this loop while the sequence has only one. The loop between the 2nd and 3rd stretches is marked by '*1*', indicating that, this time, the TRACE has a shorter gap than the sequence. In this example, the second and eigth stretches are out of register, and need to be corrected with Decor_fix (see above):
2 fixes
New> This stretch is fixed
Optimal path 7 11 16 27 49 58 71 81 91 100 113 123
New> This stretch is fixed
Optimal path 7 12 16 27 49 58 71 81 91 100 113 123




When a stretch is fixed to start at a particular residue, the threaded sequence is coloured white, otherwise the text is green.

Although Decor_slider is normally used with stretches corresponding to secondary structural units, this is not a property of the command itself. A user would have to be very sure of the TRACE in a loop region to use anything other than secondary structure to control the threading. In the above example, the second helix and third strand abut each other without an intervening residue. The alpha-strand unit is, therefore, used as a stretch. To allow the possibility for an insert or deletion between these units, the user would have to write out the guess and change the stretch between 25 and 42 into 2 stretches (and remember to increment the line count) like this:

.TRACE_GUESS_1B T 13 70
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 33
stretch 34 42
stretch 46 51
stretch 55 62
stretch 68 71
stretch 77 81
stretch 87 92
stretch 95 103
stretch 107 112
stretch 115 121


Accepting the decoration (Yes) causes the whole molecule to be built from the first residue in the first stretch, to the last residue in the final stretch. Along each stretch, side-chains are added and fitted to the density as rotamers. In the regions between stretches, the main-chain is added by following the skeleton (note the length of the loop is now known), and then the side-chains added. To carry this out, the molecule getting built must have the stereo-chemistry already generated. Here is what happens when the correct threading is used:

O > refi_in
Refi > Molecule []: p2
O > ref_gen
Refi > Molecule [P2 ]:
Refi > Define a zone [all molecule]:
O > de_sl
New> Define a .Trace_guess_* DB [1]: 1a
New> Molecule getting built [P2]:
Optimal path 7 12 16 27 49 58 71 81 91 100 113 123
O > yes
New> Result saved as :1AA
New> What map? [AV]:
New> Map used is AV
New> Skeleton used is [CAT ]: av
merge 5 42 7
ed_loop 44 49
New> Score (all & SC atoms) for 7 THR rotamer 1 18.94765 13.82479
New> Score (all & SC atoms) for 8 TRP rotamer 1 18.29142 17.89422
New> Score (all & SC atoms) for 9 LYS rotamer 2 9.83974 4.03205
...
New> Score (all & SC atoms) for 127 ILE rotamer 2 18.80953 13.31731
New> Score (all & SC atoms) for 128 TYR rotamer 3 5.43706 0.64904
New> Score (all & SC atoms) for 129 GLU rotamer 1 14.32292 11.33974
Number of gaps not built 5
NUmber with TRACE too few 5
New> Map used is AV
New> Centre-Centre-Distances Average: 3.30, max: 3.45, min: 3.24
New> Reading proteins db
New> The protein DB is now being loaded.
New> A binary file
New> There were 103 ODBs in the file.
New> Loading data for chain:HCAC
New> A binary file
...
New> Score (all & SC atoms) for 110 ASP rotamer 1 15.26557 13.56571
New> Score (all & SC atoms) for 112 LYS rotamer 2 15.46875 16.10897
New> Score (all & SC atoms) for 113 MET rotamer 3 23.26465 23.87019
New> Clean up
New> Map used is AV
New> Centre-Centre-Distances Average: 3.31, max: 3.80, min: 2.71
New> Score (all & SC atoms) for 118 LYS rotamer 4 10.18830 5.14103
New> Score (all & SC atoms) for 119 MET rotamer 2 10.32967 12.54808
New> Score (all & SC atoms) for 120 LYS rotamer 5 8.59375 2.34615
New> Score (all & SC atoms) for 121 ASP rotamer 1 9.95879 3.76603
New> Score (all & SC atoms) for 122 VAL rotamer 2 9.62073 6.45299
New> Score (all & SC atoms) for 123 VAL rotamer 3 8.63248 4.58333
New> Clean up

Although the rotamer fitting algorithms have a large radius of convergence, if the CA-CB vector of an alanine in the TRACE is too far from the density, the side-chain may not be in density. For example, in the above, Y128 side-chain is not in perfectly good density (the next 2 pictures) for this reason. Using Grab_build to rotate the resdiue and then the rotamer density fit option, produces an excellent fit



If the user does not like the threading, using No saves the guess as a new entry in the ODB with the letter A added to the name.:

O > no
New> Result saved as :1A

Using Clear_flags, stops the command with making a new save of the guess.
The contents of a guess ODB can be edited to modify the action of the DPA. The user can force a residue in a stretch to be a particular kind of residue using the TYPE keyword:

.TRACE_GUESS_TYPE T 13 70
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 42
stretch 46 51
stretch 55 62
stretch 68 71
stretch 77 81
stretch 87 92
stretch 95 103
stretch 107 112
stretch 115 121
type 101 arg

The above guess (called TYPE), forces residue 101 in the TRACE to be an arginine, for example. Up to 10 residue types can be specified. To force residue 6 to be a large aromatic, for example (see Decor_show), one would add a line::


.TRACE_GUESS_TYPE T 14 70
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 42
stretch 46 51
stretch 55 62
stretch 68 71
stretch 77 81
stretch 87 92
stretch 95 103
stretch 107 112
stretch 115 121
type 6 trp tyr phe

type 101 arg

Note that the line count has been incremented.

Specifying that certain residues in the TRACE are particular sorts of amino-acids becomes very useful when using seleno-substituted methionines for MAD phasing. As part of the phasing process, the positions of most MET residues will be known and can be directly associated with TRACE residues.

Another useful amino-acid is a tryptophan. These large aromatic side-chains are frequently found buried in the hydrophobic core of a protein and have very well defined electron density. Together with their low relative frequency in protein sequences, this means that TRP residues can be beacons in determining where we are in the sequence. Decor_guess, therefore, creates a special residue-based ODB showing the score of TRP at each point in the TRACE. If this ODB, TRACE_RESIDUE_TRP, is plotted in the O Graph pull-down, the user is able to see where potential TRP residues (or other large aromatic residues) are located in the electron density.
TRP goodness-of-fits for TRACE 1 to 122 . The highest scoring residue is number 6 in the TRACE and is indeed a tryptophan, The next highest is a PHE at residue 14 in the TRACE, see Decor_guess

Stretches can also be fixed to start at particular residues in the sequence. The following, for example, forces the second stretch to start at residue 12, the 7th at 71, the 8th at 81 and the 9th at 91

.TRACE_GUESS_1A T 16 70
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 42
stretch 46 51
stretch 55 62
stretch 68 71
stretch 77 81
stretch 87 92
stretch 95 103
stretch 107 112
stretch 115 121
fix 2 12
fix 8 81

Parts of the sequence can be excluded from the DPA threading, residies 60-120 in the sequence are excluded in the following guess:

TRACE_GUESS_EXCLUD T 7 70
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 42
stretch 46 51
stretch 55 62
exclude 60 120




Decor_yasspa (050805)

decor_yasspa <context zone> <guess name> <molecule being built>

This command generates input for Decor_slider by making a Yasspa secondary structure assignment of the TRACE and then using the a/b-units to define the stretches used by the DPA in Decor_slider. The result is stored in the DB as .TRACE_GUESS_X where X can be any group of 6 characters. If the user wishes to define residue types at particular positions in the TRACE, or to manually fix the beginning of a stretch to correspond to a particular residue in the sequence (also achieved with Decor_fix), or to exclude parts of the sequence form the analysis, the DB entry has to be written out and edited (see Decor_slider for details). The results of the analysis are controlled by Yes/ No/ Clear_flags, see Decor_slider

O > de_yas
Heap> Deleted TRACE_RESIDUE_2RY_STRUC
Util> Template size : 5 residues.
Util> There were 17
Util> Template size : 5 residues.
Util> There were 66
New> In context of residues : 1 122
stretch 5 7
stretch 10 12
stretch 14 21
stretch 25 42
stretch 46 51
stretch 55 62
stretch 68 71
stretch 77 81
stretch 87 92
stretch 95 103
stretch 107 112
stretch 115 121
Number of stretches 12
New> Define a .Trace_guess_* DB [1]:
Heap> Deleted TRACE_CONNECTIVITY
Mol> Database compressed.
Mol> Created connectivity Db for TRACE
New> Molecule getting built [P2]:
12 131 131 12
Optimal path 7 11 16 27 49 58 71 80 91 100 113 123



The decoration is essentially correct. The short, second stretch is out of register by one residue, as is the first stretch in the 'back' sheet (containing the decoration 80T->84 V in the above). This is easily corrected with Decor_fix .


Delete_object
 
delete_object <name>i ;
 
Delete any of the created objects. The user is presented with a list of all current objects, and prompted for an object name to be deleted. Any number of objects can be deleted and input is terminated by a blank line.

Dials in O (050913)
The very first version of O ran on Evans & Sutherland PS300 computer graphics systems. These cost a small fortune but had a wonderful dial-box, complete with LEDs. Subsequent versions of O also supported dial-boxes so that many people now miss using this input device in the current release. When a computer graphics system costs $50000 or more, it was perhaps not such a big deal to spend $1000 on an input device such as dials. Now that much cheaper PCs have spread to more or less every student’s desk, the situation has changed. It would be hard to justify buying an input device that costs half of the cost of the computer system! The old dial-boxes, however, were built to last. Because Silicon Graphics systems were very popular in the end of the 80’s, and the 90’s, many old SG dial-boxes are still around, waiting to be used.

For Linux O users, Joe Krahn has made available a GLUT library

http://spdbv.niehs.nih.gov/resources/

that reads the input generated by SG-dials. To understand how this works, you need to know about GLUT and OpenGL. The latter is a graphics library, widely available on a large number of different computer systems. It does not have any way to interact with peripherals such as a mouse, keyboard etc; that’s what GLUT does. All O versions now use OpenGL and also use GLUT except a SG version (there is also a GLUT SG version), and the AXP release (unfortunately, this hardware is no longer being developed). GLUT defines call-back procedures that describe how dials should work, but almost all implementations do not include dial support (SG is an exception). Joe’s library solves this problem for Linux users, allowing my call-back in O to pick up dial input. Follow Joe’s instructions, only.

Apple OSX users may have been feeling jealous but, thanks to David Gohara, they too can take those very expensive dials out of mothballs and plug them into O. But, there is always a but, you'll need a serial to USB adaptor. Apple stopped using serial input many moons ago, and the old dial-boxes use serial connections. I used the IOGear GUC232A which took 2-3 weeks to get delivered, here in the wild (you will need to install their driver). David has written a library to read these dials that works with OSX’s low level system routines, not GLUT. You can find more information on model parts etc, his homepage:

http://www.sbgrid.org/osx.php?hardware=1&id=1

Like Joe’s system, you need to tell O that dials are connected via an environment variable, like this:

% setenv DIALS SG

Note that I explicitly define that the dials are from SG because if you have dials from DEC or Sun, they’ll not work. Hopefully, I’ll get to them at some later date.
In my use of David’s routines, I have hard-wired the port, which should not cause any problem. If you unplug the dials, reset the environment variable.
I've tried my historical assortment of serial devices in the USB, but my space-ball, space-mouse did not register changes to the ball/puck.

Dial_box
 
dial_box <number>
 
This command allows one to explicitly define which dialbox is to be mapped to the dials. A search of the data base for .box<number> is made and a mapping made between the logical input device numbers and the 8 dials.
For example, if one wishes to control all of the rotations and translations for a moving fragment and have the zoom and slab active on the same box, one may use a box number 5 and have in the data base an entry
 
.box5 i 8 (3i3)
9 10 11 4 13 14 15 8
 
Dial_next
 
When several dial sets are active at the same time, this command can be used to cycle between them in a forward direction. For example, the Move_fragment command activates two dial sets, one for the rotations around the x, y, z axes, and one for the translations. Dial_next will select the next dial set on the stack. This command changes this assignment by one block of four, cycling through 4 dial boxes. For each box number, there must be an entry in the database .box<number> Default examples are included in odat/dialbox.o, dialbox_a.o and in the odat/startup.o files.
 
Dial_previous
 
This command functions equivalently to Dial_next, but cycles in the opposite direction through 4 dial box settings
Directory

directory <parameter block>

Directory listing of data blocks.Wild card * is allowed, for example:
 
dir *atom*
 
lists all datablocks containing the string atom in their name

Dist_define
 
dist_define <id 2 atoms>
 
Identify 2 atoms. A line is drawn between them with the distance. Up to 20 distances can be drawn. The atoms can be identified in a macro by using the Term_id command
 
Draw_object

draw_object <datablock_name>

Add a new object to those being displayed. The user specifies a text block in the database that contains drawing instructions in the O graphics descriptor format .The syntax of the O graphics descriptor language is rather simple; <keyword> <data> on one (for some commands more) lines.
 
The current list of recognised instructions is as follows:
 
 Begin_object <name>  Begin a named object
End_object
 end current object
 Colour <value>  value can be a name (e.g. red) or packed integer defining a new colour
 Line_type <type>  type can be dashed, solid, dotted, dash_dot
 Move <x,y,z>  moveto (x,y,z) for line drawing
 Line <x,y,z>  lineto (x,y,z) for line drawing
 Move_Atom <mol residue atom>  move to coordinate of the atom
Line_Atom <mol residue atom>  line to coordinate of the atom
 Dot <x,y,z>  dot coordinates
 Text <x,y,z> <String>  text String at (x,y,z)
 Text_size <value>  real value 0->1.0,(small->large), if supported
 Text_colour <value>  colour (e.g. red) or packed integer
 Sphere_atom <mol res. atom> <radius> <colour> sphere at atomic coords with radius and colour
 Poly <number of vertices> <xyz on separate lines>  Solid polygon
 Poly_colour <colour>  Set the polygon colour
 Instance <object name> <transformation>  Object to be instanced and datablock containing tranformation.
 Stick <mol res. atom> <mol res. atom>  Draw a solid stick between 2 atoms.
   
   
   
   
   
   
   
   

Light value(3) 3 real numbers 0->1. light colour
Surf_mode mode value(2) 2 integers, reflectance and shading method
Surf_property props(5) 5 reals defining the surface
Poly_property Integers to define the polygon properties