1. A Remote Collaboration Environment for Protein Crystallography
General Goal: Allow a team of researchers distributed anywhere in the world
to perform a complete crystallographic experiment, from data collection
to structure publication.
User at SSRL
Team Member at
Home Lab
Remote
Collaborator
Internet
Local Area
Network
Collaboratory
Manager
Multiple Collaborators can
work simultaneously
see each other’s work
Collaboratory Manager needs to be able to
decide which project the team is working on
multiple teams can be working on separate projects, eg at different beamlines
ultimate goal: Collaboratory Manager would even be able to grant access to experiments at different synchrotron sources, eg, CHESS is part of the Collaboratory testbed; there are 5 sources in the United States and about 20 worldwide.
San Diego Supercomputer Center is another Collaborator, to test whether Data & CPU resources can be accessed in a manner transparent to the user
This is a report on work done by the SSRL Protein Crystallography group as a whole.
Equipment
Control
Data
CPU

2. Designing a Modern System from the Ground Up
High Performance Computing Environment at the Beamline
Distributed Architecture
Cross Platform Compatibility
GUI’s Implemented in Tcl/Tk
Extending this System for Remote Access
Viewing the Data from a Remote Platform
Live Video Feed from the Experimental Floor
Remote File Access and Data Archiving
General Security Considerations
Delivering X-window Legacy Applications with Terminal Server
In this presentation I’ll take a historical approach.
First, I’ll describe software development that began about two years ago during the design of our newest beamline, The work predates my arrival and is the contribution of Tim McPhillips and other protein crystallography staff members.
It turns out the design decisions made for beamline 9-2 led in a natural way to the idea of allowing remote collaborators to participate in the experiment, and this has been my main focus. This part of the system is still very much a work in progress.

3. Tcl / Tk for GUI Development
Rapid Development
GUI needs only a fraction of the code necessary in C, C++ or Java.
Easy for the novice programmer!
Quick coding & easy maintenance is essential for rapidly changing beamline environment.
We’ve chosen Tcl / Tk language for GUI development
Provides a very high - level programming interface, producing lots of lines of machine instructions per line of code.
Variables are weakly typed
Source: John Ousterhoust, IEEE Computer, March 1998

4. Other Advantages of Tcl /Tk
Platform Independence
Unix, VMS, Mac, and Win32.
Scripts can be distributed without compilation and run on any computer Tcl/Tk has been installed on.
Or…scripts can be bundled with Tcl/Tk binaries and distributed as a single executable file.
Extensible in C/C++
Tcl was designed to be extended readily in C or C++.
High performance code, multiple threads, etc., best implemented as extensions. XOS library is used for sockets.
Object Orientation
The [Incr Tcl] extension to Tcl provides object-oriented features such as classes.
The [Incr Widgets] extension provides an object oriented framework for building complex widgets from built-in Tcl widgets.

5. Data Collection GUI written in Tcl/Tk
Now talk about what’s needed for remote user to participate in the experiment.
Already said GUI can be distributed to remote user on any platform, and communication uses TCP/IP sockets.
Next thing is to provide a view of the data. 7 Mb file not easy to transmit over internet link, better to make small jpeg image. If user wants to zoom & pan, or even resize, just send request for another jpeg.

6. Adding a JPEG Compressor to the System
Implemented as a separate server whose only function is to read big data files and use jpeg compression to produce a small image to send over the internet. Just wrote a new function for the XOS library to compress & send image over socket.
The server has a cache of the last 10 images it used, so if you want to go back to the last file, it doesn’t have to reload, and response will be < 1 second.
And like the DCS server, the JPEG server is multithread so multiple clients can connect, each viewing the same or different data.
Since it’s multithreaded, why not provide another functionality and allow a web server to have access to the jpeg’s also.

7. A Web-based Data Viewer at https://smb.slac.stanford.edu:8100
The result: a web-based data browser with similar functionality to the data collection GUI. Plus the ability to browse through the file system to look at any data, with Next & Previous functions too.
Use SSL v3 secure web server; users authenticate with their unix passwords, and information is encrypted.
So now we have two possible types of collaborative tools to view data.

8. Video Feeds from the Experimental Floor
Sample
Manipulation
Easy to find commercially available hardware & software for videoconferencing, but much more difficult to find API that would allow video objects to be embedded in the GUI, so that one could click on the experimental sample to move it in to the xray beam, etc.
Beamline
Instruments
Videoconference

9. Architecture for Remote Video
Current plan under development:
SGI Octanes allow up to two video inputs to the expansion card.
Low-level video demon makes images available to a video library API.
Write a multithreaded server application around the API.
Use JPEG compression now for individual frames; investigate MPG later.
Client controls the video service on demand:
Channel selection
Pixel size
Frame rate as much as client connection can handle
GUI also provides camera controls for pan, tilt, and zoom.

10. Transparent File Access For Remote Collaborators
Users also need transparent access to their files across the network.
Prototype Tcl/Tk GUI allows users to browse thru their home file system as well as their SSRL files.
Download & Upload commands to transfer data in & out--no more FTP.
Don’t have enough disk space to handle the 20 Tb/year of data--arrange for tape archiving; use HPSS in San Diego as the prototype. GUI shows a unified directory view of all files whether they are on disk, tape, or both.
If file was on tape, it would appear in its proper directory location, and the Restore menu item would allow retrieval within 1 minute (or restore entire folder).
Even if file wasn’t on disk, metadata about the file would be visible.

11. Metadata for Diffraction Images
File Header
File Parameters
Creation date
Access control list
Tape archive status
User annotation
Annotation by data processing software
Move, rename, and copy tracking
Thumbnail View
This metadata is stored in a database; each file is registered in the database as soon as the data are collected.
Metadata gives files far more properties than they would have in a unix NFS filesystem. For example, the user can keep a history of move & rename operations. User can also annotate file, grant access rights, or permanently delete. In addition, application programs can annotate the metadata, for example that a particular file was used in a calculation.
Larger JPEG View
Larger JPEG View

12. Architecture for Remote Archiving
The File Location Server mediates between the client and file storage. When a directory listing is requested, Server looks in the database and merges the views of data on tape and on disk.
The DCS server contacts the File Location Server when new data are collected.
The Archive Manager Script packages up old files for shipment to tape storage and then deletes them from disk.

13. General Security Architecture

14. Legacy Applications Can Run Within X-window on Metaframe
WRQ Reflection-X
Showing SGI Desktop at SSRL
Data Analysis Application
Running at SSRL
SGI Desktop
at home lab
Windows
Terminal
Server
at SSRL
Seen Through
ICA Connection
So far the discussion has centered around collecting & managing data.
Data analysis will be accomplished mainly by legacy applications
Most of them are free downloads for academic users
Platforms are typically different flavors of Unix, and web-based interfaces
Total analysis time varies from hours to months
Progress at beamline depends greatly on rapid analysis while still at the beamline so experimental choices can be made.
Make unix-based legacy apps available to remote collaborators through X-windows interface. X-applications are viewed on WRQ ReflectionX server running on a Windows Terminal Server at SSRL. Remote user then gets the graphics through the ICA channel which is band-width friendly.

15. Summary: Four Platforms for Remote Access
Remote Collaborators will be able to access the experiment through four platforms. In each type of connection, security arrangements are indicated.
Traditional connection to Unix host through ssh, possibly with X-windows
Run the multiplatform GUI distributed by SSRL, to access distributed control system, images, video, and file browser.
Web interface for simple tasks
ICA connection for data analysis with legacy applications