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.

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.

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

.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

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

---

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.