| Design Features |
This section is for programmers interested in technical details of the implementation of PE. It touches upon some design features that may not be obvious when using Protein Explorer.
For the RCSB, the URL to fetch a gzipped PDB file for 9dna is: www.rcsb.org/pdb/cgi/export.cgi/9dna.pdb?pdbId=9dna&format=PDB&compression=chime
Javascript also knows when Netscape is busy, namely, when a document in a frame has not completed loading (busy status is turned on by onUnload and turned off by onLoad). This avoids clicking on links or buttons before all the relevant forms and documents are in place.
The Explorer (one molecule at a time) has a Ready/Busy indicator below Chime. The Comparator does not have such indicators but internally obeys the same rules. This is because the Comparator would need three separate indicators (one for each Chime and one for Netscape) and this seemed not worth the effort for programming nor the screen space required nor the visual distraction from three indicators.
To see the unscrambling in action, issue the command "javascript top.db(true)", which turns on a debugging mode. All messages will now be reported to the message window, prefixed by S (for Scrambled) and then U (for Unscrambled).
Temporary disconnect for loops. The unscrambling function requires that out-of-order messages be stored until they can be passed out in order. The NMR [Auto] (automatic display of each model in sequence) uses a looped script which can easily generate thousands of messages. Unlike some non-looped scripts, there is no need in this case for javascript to "scrutinize" the text of each message. Therefore, a special mode was provided in unscramble() for looped scripts -- in this mode, message numbers only are unscrambled, without storing the messages themselves or passing them onto the message text processing function. When every message number is accounted for, and the interrupt has been processed, Chime has completed the script. However even this took too long (javascript being an interpreted language) and after a long period of viewing the [Auto] loop, and after Chime had processed the interrupt which stops the loop, it would take many minutes for unscramble() to process even just the message numbers. During these minutes the user must wait while nothing appears to be happening. (Actually unscramble() is going at top speed but nothing happens on the screen and the user is locked out by the "busy" condition.) Therefore a third mode was implemented, called disconnect mode, to make the [Auto] loop display recover quickly after an interrupt. In disconnect mode, message numbers as well as message texts are simply discarded. After sending the interrupt, a reconnect operation is initiated. In order to determine when Chime is idle/ready, this function checks at one-second intervals and turns off the "busy" flag only after a second in which no messages were sent by Chime. This may not be a bullet-proof method but is the best I've come up with. The worst consequence could be that left-over messages might come back unexpectedly after reconnect signals that Chime is "ready". This would likely generate an illegal condition in unscramble() which would then recommend closing the window (ending the session).
Surface calculations. Calculation of surfaces and coloring them by distance (QuickViews DISPLAY Surface or Contacts, or in Advanced Explorer, coloring a surface by electrostatic potential, or lipophilicity potential) require significant time. In QuickViews, a small window appears apprising the user of this. For large molecules this may take several minutes, but there is no workaround.
Retaining the selected subset. Several options in QuickViews utilize scripts that involve selecting subsets, but when finished, preserve whatever was selected before the button was pressed. These are the Water, Ligand, and 2o buttons, and DISPLAY Vines or Cartoon. Restoring the initially selected atoms is accomplished with one final "select temporary", where "temporary" was defined as the initially selected subset. Selecting a defined token is exceptionally slow in RasMol and Chime when the subset is large. After loading a large molecule and pressing the Water button, it is quite possible to have the browser and Chime freeze for a full minute or more. On the other hand, if all atoms are selected prior to these operations, the script can end with "select all" which completes instantaneously. Therefore, PE notices whether all atoms are selected and avoids selecting the defined temporary subset in that case. If a subset of the atoms are selected, and if the "select temporary" operation is estimated to need more than 12 seconds, a warning alert informs the user that selecting all will speed up this operation, but offers the option to proceed slowly, preserving the currently selected set. This implementation required that we estimate the speed of a "select temporary" operation in Chime separately for each client computer.
Determing Chime's speed on each computer. With the help of Diana Ditmore, we first tried estimating the computer's speed with a javascript integer counting loop. Our implementation seriously underestimated differences in computer speeds, and completely failed to predict the speed with which Chime could execute "select temporary" for a test set of 45,000 atoms (1g3i). This remained true when we included random number and square root operations in the loop. We then implemented a method in which a separate window is opened in which a very simple invocation of Chime is used to measure the actual speed of "select temp" in the largest PDB file already contained within the PE file set, 2hhd.pdb. On our reference computer (667 MHz PIII), this usually took 220 milliseconds (though it ranged between 170-330 in replicate tests). We arbitrarily defined this as a relative Chime speed of 1. A 100 MHz 80486 computer had a relative speed 20-fold slower (0.05). A 1.7 gigaherz PC has a relatie speed of 1.7. We suppose maybe the very fastest current computers could have a relative speed of 5, though we have not tested one. Our implementation allows for a maximum speed of 22, allowing for some future increases in speed. PE will show you the relative Chime speed it has determined if you enter the command alias speed. This also gives the option of re-determining the relative speed on the next startup of PE (by erasing the cookie). The document that determines the speed is speed_ch.htm.
The relative speed is determined five times and the average is saved as a cookie with a one-year lifetime. Based on the total atoms in the PDB file, and the number of atoms selected, we predict the seconds needed for the operation requested. (See predicted_sec() in util_top.js.) You can see these predictions if you enter the command speedwatchon before e.g. pressing the Water button. If the prediction exceeds 12 seconds, the user is warned and given the option to cancel, and it is explained that if all atoms are selected first, the operation will be much faster. For test purposes, here are a series of increasingly large PDB files (total atoms in parentheses): 1IGT (13K), 7AHL (23K), 1G3I (45K), 1AON (59K), 1FFK (64K), 1JJ2 (98K). Larger oligomers including huge virus capsids are available from Probable Quaternary Structures (accessed through the Mol Info window).
The first speed detemination is thown away because it often spuriously reports 0 milliseconds (for reasons unknown). Merely reloading the speed-measuring document did not prevent this (if it was the first time Chime was loaded in the Netscape session), so the window containing that document has to be closed and re-opened. Furthermore, on a very slow computer, the second determination may also be 0 milliseconds, so the second determination is thrown away if it is very small. Thus, it takes 6-7 determinations to get five good ones for the average.
With downloaded copies of PE on Macintoshes, version 1.98 Beta of PE revealed that Chime often fails to load into the window containing the speed_ch.htm document, causing PE to fail to start (since no Chime speed is ever reported). Therefore, in PE 1.981 Beta, for downloaded PE on Macintoshes, the speed test is not attempted. Instead, the user is asked whether the computer is a G3 or a G4, and a rough speed is recorded based on the response. Advanced users may determine the speed of Chime on their Mac by running PE on-line and entering the "speed" command. This relative Chime speed value can then be entered in the next session of the downloaded PE for improved accuracy.
Slow color scheme scripts. Several color schemes in PE use Chime scripts (rather than being built into Chime), and are designed to color only the selected subset of atoms. Limiting them to the currently selected atoms involves using the defined "temporary" set in several selection commands, as well as restoring it with "select temporary" as the last command. Because these involve several selections of "temporary", they are even slower than the operations discussed above. PE's predicted seconds for execution takes this into account. If more than 12 seconds, PE reminds that selecting all prior to applying the color scheme will make it much faster.
| Known Limitations |
Fixing the following limitations is not worth the time required, so these are expected to remain indefinitely.
| Future Plans |
| Version History |
Here's a short version of What's New.
This update of the Spanish translation of PE was begun in early 2004 with PE 2.1, before PE 2.2 was released. The following improvements (already released in the English versions PE 2.2 and 2.3) were added to the Spanish version. In nearly all important respects, 2.25 is equivalent to 2.3. The major enhancement in version 2.3 that is lacking in 2.25 is the more flexible control of the size of PE's window (from the FrontDoor of PE 2.3).
Enhancements and Changes
Bugs Fixed
Documentation / Terminology
Chime 2.6 SP4 has a newly functional "show version" script command, making it much easier to determine its version in IE. However, it was necessary to maintain compatibility with SP3 plus SP4 in IE in order to avoid suddenly locking out instructional computer labs where software changes take a long time to be made (such as the one I teach in at UMass). Because of the difficulties determining versions of Chime 2.6 SP3 and earlier in IE combined with the requirement for a new mechanism for SP4, a major overhaul of the startup mechanism of PE was required. These changes are detailed under Chime Testing.
In addition, there was an unanticipated change needed to support IMBIF, which required additional recoding.
The background of the Help/Index/Glossary
was changed to light green to make its connection to the green
circled question marks
on every page more obvious.
*** ENHANCEMENTS TO FUNCTION ***
*** ENHANCEMENTS TO DOCUMENTATION ***
on any control page within
PE.
, or from the Molecule
Information Window. It will take a few more releases until this is
reasonably complete.
script "http://www.umass.edu/microbio/chime/shared/cs_amphi.spt"