A WORKSHOP ON GRAPHICAL USER INTERFACES
FOR SYNCHROTRON PROTEIN CRYSTALLOGRAPHY
Brookhaven National Laboratory 19-21 March 1995
------------------------------------------------------------------------
Welcome and opening remarks
Denis Mc Whan, Associate Director Basic Energy Sciences, BNL
------------------------------------------------------------------------
Interface Design: Guidelines, Practices, and Questions to Ask
Brad Blumenthal, Elec. Eng. and Comp. Sci. Dept., Univ. Ill. at Chicago
brad@eecs.uic.edu
Subtitle: HBI human-beamline interaction
Outline:
Fundamentals
Literature
Standards and consistency
Human-computer techniques
prototyping and evaluation
Suggestions for beamline interfaces
Design outside the box. design for the environment
Design for the handicapped
Ignore the experts
Literature
Schneiderman Smith and Moiser Making it macintosh
Wruman: Information and anxiety: organizing and understanding
Norman: Psych of everyday things: affordances and feedback
Laurel, Brenda: specifics of design
Will focus on how to present information
Define affordance
Approach a multidisciplinary audience
The Literature --
Wurman: Information Anxiety
Five ways of organizing information
category
location
continuum for comparisons
alphabetical
temporal finite duration
Information vs. understanding
An acre is .... Can you pace out an acre?
Norman: psychology of everyday things.
Gulf of execution and affordances
Gulf of evaluation an feedback
Execution
form a goal: get something in you head
find an affordance: find a handle on accomplishing the goal.
vertical vs horizontal handle. (jj gibson)
two hands separated to provide safety
perform an action:
Evaluation
perceive a change
interpret your perception
match interpretation to goal.
Brenda Laurel Art of human-computer interface design.
Prototyping and evaluation technique examples.
"whole-product interface"
multi-disciplinary cooperation.
There are two disciplines: operators, experimenters.
Maybe even subsets of each.
Standards
These are religious wars
There to establish consistency within a context.
Define the community of users: operators, users, chemists, x-
tallographers.
Consistency:
This is the root of guidelines. Carry one into unfamiliar
circumstances.
Example: He can program his mac to look like emacs or like photoshop.
Choose whichever based on the context.
Highly dependent on context.
HCI technique.
Observe: need to know community of practice, what they are like.
Design and prototype: Use paper -- easy to throw away.
Evaluate: again and again!
Implement: put into code, try it and refine.
Evaluate
Refine
Repeat....
Evaluation techniques:
User observations
PNAMBC studies -- "pay no attention to that man behind the curtain".
You play the role of the computer.
Observational
With friends in vitro
In situ -- after 4 days on the beamline. Test on a
certified idiot.
Longitudinal studies -- see how they become expert.
Evaluation tools:
Don't use introspection -- don't think about what YOU do. Test negative
stuff!!
Notes: Write down what you see.
Audio/video tape. See how they use it. Video is better.
Write logging software -- meter it. record every user click and time-
stamp it.
Think-aloud protocols. make the user tell you what he's thinking about
as he uses it.
Problem -- these all degrade performance. One could do post-hoc
analysis -- debrief the user from video record.
Evaluation set-up:
Make it realistic -- tired, stressed
In situ, if possible
Video
Running a study:
Smile and nod!
NEVER explain. (enough said)
Write canned prompts: "What else did you expect to see."
Remember -- the software is being tested, not the user.
Prototyping techniques
Lightweight prototyping (sequencing)
Write a scenario, storyboard, screen design.
Paper prototype PNAMBC interactivity.
Middleweight prototyping (interactivity)
SuperCard, Director, ToolBook, etc
If it's useful, scan in your paper design
Development (bullet-proofing)
Refinement of a scheme:
Specify (implement) prototype (evaluate) problems (think) specify again.
Hartson and Hix:
During analysis, figure out what was missing, where it should go,
then do it.
Keep track of design decisions (good notebook).
Summary of HCI technique
Evaluate-implement cycle often
Identify users by community.
The user is always right!!
No user error, just bad design.
Make fast lightweight cycles of testing.
Suggestions for beamline interfaces
Design outside the "box" (computer)
What is the BEST solution; don't be limited by available software
or hardware.
Design for handicapped
Ignore experts.
Design the whole experimental environment!
Answers are not always on line!!! (For example, a checklist on computer
isn't good -- one needs paper)
Connect on-line world to off-line world.
Make interface reflect the structure -- blue book <=> blue panels in
GUI.
Communication with the user:
Design should communicate affordance and feedback
Designs could facilitate experimenter/operator communication
(communication between two distinct communities of user).
Let operator and experimenter communicate on their own terms.
Design for handicapped:
Newell's handicapped soldier -- deaf, blind, mobility impaired -- scared
Sleep deprivation -- short-term mem., longterm, inaccuracy,
irritability.
People running expts have Alzheimer's.
Techniques for handicapped:
Front-load cognitive tasks
Color code things that need to be done together.
Constraints -- make sure necessary steps are done in order.
Fill in the blank -- make each blank show what's required and
which is optional.
Ritual
Ritual vs Habit: Thoughtful repetition of unnecessary vs.
thoughtless repetition of necessary.
Ignore the experts
Bad news
They have techniques, but not answers.
They don't understand the beamline. Make them use it.
Good news
The beamline comm. of practice has the answers. Do what is
necessary and what works.
Summary
Skim Wurman, Read Norman, Pick and choose from Laurel
Observe, prototype, test, refine, evaluate, repeat,...
Design the "environment" Reflect this in the interface. Acknowledge
the handicaps of the interface.
------------------------------------------------------------------------
Statement of the problem, Charge to the workshop
Steve Ealick, Cornell
SR Beamtime is a limited resource. The quality of synchrotron data is often
compromised by unfamiliar procedures.
Solution: Create a standard GUI that allow the user to design, preform and
evaluate a crystallographic expt. Allow traveling scientists to see similar
thing each place.
Considerations for GUI design
Reduce training effort
Increase beamtime efficiency
Increase flexibility
Standardize GUI appearance
Minimize user errors
Produce better data
Expand opportunities for non-specialists
Functions
Control station alignment
Create exptl. strategies
Setup and control expts.
Evaluate data
View images
Assign hkl indices
Integrate data
Tabulate statistics
Calc and display eln' density
Monitor progress of expt.
Trouble shoot
Questions
What functions from GUI?
What is minimum set of truly common features?
What info. to pas on mmCIF?
What is final product data: hkl F sig?
Who will do the work?
How do we incorp. existing software?
What do we do next?
------------------------------------------------------------------------
Jim Pflugrath, Molecular Structure Corp.;
Go back to EEC workshops. Bricogne got a eureka grant.
Goal was to get programs to look and act the same.
On commercial side -- ideas are different.
Users span wide range of expertise Best sol'n: don't let user collect his own
data!!
There should be 2-3 people per beamline to do the work.
The GUI becomes a real person.
If you need a GUI, can it be just one button?
Tower of Babel syndrome -- Experiences from one facility didn't transfer to
another one.
Get rid of it by working on making things the same. Think of driving a rental
car: You expect to find certain things in certain places.
Once we get standards, do we write our own, do we write pieces? Will
everything be one-off? How can we share?
Cooperation or competition -- neither is bad!
Do we talk about beamline operator or user? He (MSC) focusses on the user!
Even though beamlines ar different, could define similarities and put
components together.
At old EEC workshop -- had haves and have-nots (Those with programs and those
who wanted them).
Details -- do we make a slits widget, a monochromator widget, or do we each do
these in his own way?
Can we see how to reuse code?
I've used WordPerfect must use MSWord now. They're not the same! It's like
using different synchrotrons. We want our code to distill to what users can
use.
------------------------------------------------------------------------
Bob Sweet, BNL
We notice a dichotomy:
X-ray beams are getting hotter and the equipment to use them is becoming
more complicated.
But, potential users are becoming both more numerous and less
experienced.
There is a tremendous need to make the user interface to these facilities as
easy to use as possible.
We want to build GUIs to drive the entire expt. The chief motive is to assure
first the quality and then the quantity of the data that are produced.
The experimenter must be able to control the measurements and to assess the
merit of the results in ways he can understand and control.
We want to consider the function that the user wants to perform and the sort
of software that these fucntions demand:
THE GRID OF CONTROL!
FUNCTION --> BEAMLINE DATA DATA
| CONTROL ACQUISITION REDUCTION
v
Check status Check crystal Check the start
INTERFACE TO Fix problems Choose strategy Monitor
USER Choose wave- Take the data progress
length Check the result
Alignment Setup (etc!) Generic data
CENTRAL CONTROL Monitoring Iterate reduction
Monochromator Monitor
Goniometer
DRIVERS/ Motors Shutter Disk
DEVICES Counters Detector Network
FAST Disk
Then these must be integrated into an accessible package. Can we define
common themes and establish standards for beamline interfaces?
------------------------------------------------------------------------
The MARMAD/OptiX GUI at NSLS X12-C
John Skinner, Biology Dept. BNL
The Fundamental Concept:
These were all command-line-driven programs; we have produced a GUI that
simply constructs text commands and pipes them to the program. In every case
the original programs can still be run on their own -- with no GUI!
The Data-collection System:
Beamline Hardware:
A MAR Research 300mm imaging-plate scanner mounted on the theta arm of
an Enraf-Nonius FAST (CAD-4-style) Diffractometer.
Standard beam-line stuff -- alignment table, counters, monochromator
drive.
The diffractometer is controlled by a many-process system, all under control
of a GUI:
MAR detector drive -- MARdc
Diffractometer drive -- madnes
Image transformation process -- IPXform
Our GUI forks off madnes; communicates with pipes that link standard i/o
channels.
The layout of the GUI matches the tree structure of madnes.
Each level relates to different parts of data collection and analysis.
There is a "standard" menubar to give file control and to direct to other
levels.
Other features:
Scrolled text window for text output, including an adjustable paned
window.
Command line for conventional text input.
Levels that are most used are DET and COLLECT. Both show Datum parameters and
status of MAR scanner --
Sliding bar to time exposures, erasures, etc.
Color coding to show step in the process.
DET (immediate control)
Set Diffractometer
Test exposures -- either oscillation images or stills. Choose
detector size: 180mm or 300mm
COLLECT (Programmed image recording -- Most users use denzo and mosflm
for data analysis.)
Chart to set up multiple sweeps of data
Useful to distribute data to several disks
Can do "Friedel Flip" data collection automatically
Will eventually program for multi-wavelength.
Data collection in progress: Io is being measured by Optix as an exposure is being taken.
Other sections -- mostly "charts" for examination and input of parameters:
Find reflections for indexing
Index
Refine parameters
Predict a pattern
Display of images and predictions with Daresbury graphics routine.
Beamline Control Program -- OptiX and Ace/GUI
OptiX is a subset of a larger prgram used by beamline personnel for all
motors: The Ace/GUI -- GUI controlling the motor-control program ACE.
The Ace/GUI program is similar to madnes GUI in layout and architecture:
Scrolled text output
Command-line window.
Menubar to direct control
The GUI is general and can be used at any beamline that uses Ace. Ace has a
macro facility.
OptiX is an interface to macros written specifically for X12C.
It gives users only what they need: minimize errors by limiting capabilities
Two main operations at X12C
Realign after reinjection = adjust slits and table
Can use scans with optimization or our invention: the Tweak Box
There's a "Realign" button that does 4 linked scans.
Realignment in progress with a vertical scan being performed.
Change wavelength
Direct move
Do scans
Analyze absorption spectra for inflection and peak.
Analysis of a scan of wavelength showing fluorescence from a heavy atom.
Another important feature is that OptiX communicates with madnes directly:
When the wavelength changes, this is recorded by madnes.
OptiX can control the x-ray shutter that is ultimately under madnes
control.
We have all our beamline documentation on the WWW. It's especially useful for
users to look at before coming to BNL.
Lessons learned over the last couple of years:
-- Use a builder = BuilderXccessory = BX
-- Try to watch the users use the program
-- Don't expect users to follow instructions or read documentation!
-- Anticipate and protect against errors -- for example, an attempt to
realign w/o the beam
All this is well worth the effort. Users are more confident and relaxed and
things are more reliable.
------------------------------------------------------------------------
The Daresbury user interface PXGEN and the use of UIM/X
Steve Kinder, Daresbury Laboratory
Hardware at their beamline -- 4-circle goniometer, MAR scanner, indigo, vme
crate for expt. control, a file/compute server, 4gb of disk, backup tape. All
this bridged to network.
PXGEN
Designed to be general xtallog data-acquis.
Motif-based GUI
Build using uim/x
Uses BNL modified madnes and ADSC MAR control software
Client-server (BNL) model
Development reasons
Wanted to move from single-process data acquis. and expt. control. But,
in multi-process platform, need something to hide complexity.
Wanted to drive everything from the one mode.
Has separate windows for each control and status function.
They're able to iconize their command/scroll portion of the interface
Lots of use of grey-outs to turn off useless commands.
Extensive use of pop-up menus rather than a table.
Has a slider to show how many exposures have been taken.
Lots of choice of units -- mm, cm, m (maybe too many choices).
Has some functions password protected.
Future
Auto table align
Auto x-tal align
Control of 2theta
Display of images
Exafs scan
Improve status interface
Improve mar control interface feedback
Temp control
Allow gaps in data
Take a still
Auto. mono calib.
More intuitive interfaces for mirror posit., x-tal align, beampipe
adjust
VME control of Enraf goniometer
Dose-mode data
Drive MAR base and rot'n axis with this gui
------------------------------------------------------------------------
X-GEN and the Cirius2 Environment
Andy Howard, Molecular Simulations, Inc.
Cirius2 application environment
Integrate scientific methods
Modular for extensibility and prototyping
Client/server support in heterogeneous networks.
Complete development environment
algorithm
user-interface tools
interactive graphics
system services
Modality vs. amodal -- First - timing defined by events, latter,
determined by user.
They try to be amodal to give user control.
User view -- look at 3 or 2-d data in several ways
The Application-view user interface talks to external and internal stuff.
Cerius 2 user interface
Natural separation of algorithms and interface
Appearance controlled through ascii def. file
Command-mediate interaction with application - script loggin and replay.
This is a dialect of TCL.
Amodal env. puts user in control
Network support
Client/server links -- not just x-windows
Fully heterogeneous networking
Detach / reattach application tasks
User-selectable server nodes at run-time
X-acquire GUI
Work: a total of 9 hours writing this.
Shows gui-def language file -- lots of obscure text
Application def. language file equally obscure
Various panels for each process.
Uses a "card deck" to choose panels.
Choose detector/goniometer type with pop-ups.
Lots of possibilities.
Fonts rescale with panel rescaling!!!
------------------------------------------------------------------------
The MAR Research/ADSC Software
Chris Nielsen, ADSC, San Diego
MARDC, IPXFORM, etc.
There are two GUIS for controlling the expt. and taking data. Two more for
handling data-reduction.
Made with BX
Andy Arbeit wrote one. The processing GUIs are new motif-based software to
control denzo and mosflm.
There's an overall control box with 4 buttons to choose step in the process.
There's a status box, including prediction of completion times, etc. How much
disk space.
There's a manual control window.
There's a snapshot window with a dummy file name that prevents file overwrite.
The setup window can be saved. Chose anything you want, including comment.
The Image-display stuff is like xvip: very nice! arbitrary cuts. nice grey-
scale adjustment.
Data reduction:
Denzo interface -- documentation at the bottom. Uses Properties boxes like
BNL.
Captures stuff from output and puts it into a table.
There's a refinement-scheme table too.
The scaling routine provides push buttons for control of which paramaters
should be varied, again like BNL's MADNES.
Can run interactively or batch -- Gui helps for both!
------------------------------------------------------------------------
Plans at ESRF for a common data-acquisition software
Francis Epaud, ESRF Experiments Division Programming Group (EXPG)
Device-server model
Unified model to access devices
Object oriented
Each device is an entity with its own data and behavior and a unique
name
Classes written in C
Classes are derived from a root class and can be combined
Class contains descriptions of the device and the methods to apply to it
Classes are accessed by a single APE
Device
Can be a physical component (motor, encoder,..) ensemble of components,
or logical device (linac, )
Has a unique name: /domain/family/member
ex. ids/slit/1
Resources to define setting (static database)
device_name/res_name
ids/slit/1/hgap = 12.5 ..
Controlled by commands devstop, demove ,
Has its own state handler
Server
Handles the device
Process that offers services for clients who want to access the served
devices
Acts as a daemon waiting for command
Uses rpc for client/server commun.
At startup the server exports names of devices it serves and also the IP
number of the host where it runs to a manager called "network manager"
Client
High level process for user interface and to access the server
At startup the client imports devices it wants then communicates
directly with the server
Communication is nicely organized. Each device defines itself from databases.
Conclusion:
Advantages
Unified API (?), easy to understand
Not necessary to know rpc programming
Fully distributed architecture
Runs on a lot of platforms
Well adapted for slow control
Problems:
Not deterministic ( > 10 ms)
Client/server = master/slave
No asynchronous call from server to client -- must poll!
Some clients :
Slits control (x11/motif gui_)
Vacuum control
Beam shutter control
Ipc (image acquisition)
SPEC
KHOROS image-processing freeware
can be used for control
glyph development
Main control panel
synopsis of the beamlines
some controllable ares
cal other applications - slits, attenuator, spec
display main params of beamline.
Nice icons to describe functions in the GUI
Graphics to show beam status and hook into beam steering, tuning, etc.
Modular data-acquisition system
This avoids rewriting all the software for each acquisition system
One has a scalable architecture
Easily increase functionalities -- data reduction, transfer
Easily increase performance (cpu, number of cpu's
Hardware independent
Uses standards:
unix, posix, os9
C
x11/motif
psd sockit , tcp/ip, rpc, nfs
vme vxi
motif style guide.
Acquisition memory structure
Try to structure it for collection of images of various sizes.
Data access still has to be hardware dependent.
ONLINE display
Visualize raw data in the Acq. Mem.
2D integer data only
Use x11/motif
Complete control over generalized image.
Want to approach 1 image/per sec.
------------------------------------------------------------------------
EPICS and beamline control at the APS
Harvey Rarback, CARS, U. Chicago
EPICS: Experimental Physics Industrial Control System
A bunch of people are using it -- telescopes have adopted it.
Has a lot in common with ESRF system: Inherently distributed.
Based on a distributed run-time database.
A set of objects(records) with associated fields.
Database runs on real-time unix kernel -- autonomous.
Can control expt. without external control.
Beamline user drives it.
Although control of the accelerator is pretty much fixed, expt. is diferent --
may change rapidly.
Components that come with EPICS:
display manager
alarm manager
archiver
sequencer
C applications.
There is no polling -- when data change, everyone is told.
Database resides on server - now only motorola crate computers.
Client machines can be anything almost.
Advantages
Distributed
Many work stations talk to same ioc (?) and devices
Only one cable to expt.
Scale: add cpus easily
Share development with CATs and facilities
APS accel, APS beamline, LANA accel, CEBAF accel, DESY accel
Good tools for creating simple displays (MEDM)
Can download time-critical code into VME crate
Can easily run other applications (IDL, SUPER, SPEC, WINGZ) on work-
station and talk to crates.
Disadvantages
Big hump in learning curve -- not trivial to learn.
Attributes
EPICS is not the aps control system Just tools.
Minimizes custom coding
Uniform operator interface
Event driven, no polling
High performance
Process >5000 records per second
------------------------------------------------------------------------
Data reduction: What do we need, a GUI or a Text Editor?
Wladek Minor, Purdue University
A problem for most crystallographic expts:
Make software solve hardware questions
Make hardware solve software problems
What is the point -- a Graphical User Interface is really an i/o tool that
allows the user to concentrate on the expt. with little concern about how to
run software
We need a better judgement of the data -- what is good and how do we fix it if
it's not?
Need to verify that everything is working ok
Experiment
alignment
strategy
feedback-> processing: this processing guides the experiment
automatic processing requires a "header"
Tried auto processing -- got 3.8% on 1.7Ang data. It was wrong -- the key was
that there were lots of rejections.
The GUI (image-display program) was misleading, except that it confirmed that
the data-red'n had done the best it could.
------------------------------------------------------------------------
GUI Construction with AVS: Integration of CCP4
David Wild, The Salk Inst.
This discussion is of the use a data-flow visualization environment: AVS
(application visualization system). The example shown will be in the use of
xtallog. data.
He likes it because it has to do with passing data between packages without
intermediate visualization of the data.
CCP4 is useful -- standard data formats.
Help provide visualization tools for 3d 2d, 1d data
GUI for stand alone programs
GUI for network programs.
He sketches out many of the steps in the structure solving and analysis
problem.
There are defined formats for atoms, reflections, density maps.
Formats are portable across platforms by use of HDF type methods.
He uses pipes to handle communication between gui and command-line driven
programs.
GUI sends strings to characters for control to algorithmic programs.
AVS has network editor (coding network) to set these things up.
Uses AVS own widget set -- will become motif widgets.
Provides graphical (dial) or type-in input.
A sequence of procedures really appears as a big chart of one quick GUI for
each module -- example is watpeak -- 4- 5 steps.
So far he's just writing output to text window. This can be filtered, he's
not done it.
------------------------------------------------------------------------
Program Interfaces with the World-Wide Web
Dave Stampf, PDB, BNL
Look at the man behind the curtain.
He is using various WWW Clients as as a "super" front end for programs to run
at BNL.
Describes how the PDB uses WWW for browsing through the data-bank.
What technologies underlie the www (http, html, mime)
What's in the future?
What is "Mosaic"?
One of many instances of a prog. to work the WWW
Display formatted text
Access net resources
surf hypertext links (url)
execution cycles
retrieve files
Spin off "safe" programs on our system" (xpsview, rasmol)
The PDB
Growth: 3500 entries, doubling every 2 years
2000 access/day, factor of 6 eery two.
Staff
1 programmer working on user interface
User community requirements
Universal access
Simple access
Complete access
There must be a gateway program to drive stuff at the pdb
Provides access to database search engines.
Right now it's used to search a long list; very soon will have
sybase file.
There will be CPU servers accessible for various user functions:
structure validation, etc.
Documentation in hypertext
There's a file server for export of files.
SCOP is a utility to browse through to find structures.
PDB browser -- 1000 lines of perl is the gateway prog.
It does stuff at pdb.
Can also do stuff at home (rasmol to view in 3d)
Underlying technology
http: similar to ftp but without overhead
data with embedded links
transaction based. you ask for, we send, that's it.
sneaky uses -- telnet to port 80
html: hypertext markup language
think structure, not form (primitive)
advantages -- runs everywhere, looks reasonable everywhere
disadvantages -- "" "
MIME
Specify file type in file
advantages -- unlimited use
disadvantage -- ""
content-type: chemical/x-pdb
vs content-type:text/plain
Can Mosaic be a super front end?
good for on-line documentation
can run programs locally and remotely
diagnostic uses
quick and dirty access to information
back-door access to the data
Future
CCI and other technologies are aimed at interactive question
a long way off and unproven
you may want to extend basic protocol yourself
Frustration may set in with user community.
The network is a living lab -- there will be more and better protocols
ahead.
------------------------------------------------------------------------
D2AM and the Control of the IBS beamlines at the ESRF
Eric Fanchon, IBS, Grenoble
Outline:
overview of beamline
principle of the control software
architecture of the scripts
beamline procedures
data-acquis.
GUI development
D2AM Dedicated for MAD.
Double x-tal after cylindrical mirror -- second x-tal sagitally bent for
focussing
Shared between PX and MS. Requires some flexibility.
Two types of graphics - dedicated graphics, then GUI for spec and "nemo"
NEMO is high-level interpreted lang.
No distinction between beamline control and data-acquisition.
General features
flow control
for and while loops
if-else etc.
can define types
can define functions
can run compiled user libraries for x-tallog calculations.
beamline control
simulation mode
other standard things to interact with esrf client/server system.
A simple script will define the functions of the process.
Has a complex script for mad data
Interaction from madnes back to the data-collection prog. to control orienta-
tion, etc.
GUI is two-process system. Stdin gui-pipe
nemo msgs. designed for gui updates.
Continual update of progress -- sliders that move, for example.
Have Xnemo for operators and Bionemo for users.
------------------------------------------------------------------------
Some GUI-development tools we use at the ESRF (with some example applications)
Peter Daly, ESRF EXPG
TKL is a useful tool. Doesn't take much to learn.
Several subgroups within their software group --
control of instruments, using spec
gui group
Have a phase-space application. Generated by student in 2 weeks.
has it linked directly to mathematica -- plot windows come from there.
Second tool - made with UIM/X
Done with Image Magic - (on the net)
Lots of tools for analysis of a pattern -- sections, 3d plots, etc.
------------------------------------------------------------------------
IDL as a Builder for Beamline GUIs
Harvey Rarback, CARS, U. Chicago
IDL and PVWave used to be the same except for the widget sets. Sold by
research systems inc.
Interpretive language, but it's quasi compiled.
supports a basic sets of widgets common to all platforms -- mac, sgi, sun....
has ordinary motif set
Can draw graphs.
Can write you own compound widgets that can be instanced.
Lots of output devices.
Has z-buffer output. Will support SGL later (SGI graphics)
Can do external calls to C or fortran routines that call idl stuff.
He wrote a demo. that reads fuji imaging-plate scanner data. Took 4 hours to
do this.
Out of the box: lots of nice widgets -- allows one to do stuff quickly.
Nice image display!!
He wrote a quick row/column display.
Lots of other stuff -- 2-3 pages of code do it.
------------------------------------------------------------------------
Construction of a GUI for an ISA-based MCA system
Kate Feng-Berman, BNL
Initially wrote something under ACE to run the mca
Old MCA pkg. provides enough functionality from keyboard, But not user-
friendly. Developed GUI package.
Build fundamental gui with bx
Added ISA?
Then tuned it up in C-code to make it fast
------------------------------------------------------------------------
Data tranfer and management associated with a CCD-based area detector
Dan Thiel, Cornell
One needs one system to accumulate data, one to process.
How do we avoid bottlenecks?
How do we store (for processing) and archived (for safety) the data?
How do we manage to process the data?
Detector on line for 18 months. 20 sec for 8mb
Can't transfer until no data are being collected.
Needs three different computers.
Correction of images is slow -- 3 min for 8mb image
Data processing requires user intervention.
Data archiving is slow.
Have to transfer from PC to faster machines -- often use the machine fill
times to deal with it.
Will try various fast network options -- FDI, ATM, etc.
Need to speed up the frame-correction process.
------------------------------------------------------------------------
Siemens graphics-based software for control and analysis of diffraction
experiments.
James Phillips, Siemens Analytical Instruments
Frambo -- indexing and data collection for wire detector
Smart -- same thing for ccd detectors.
Support histar -- wire detector
and SMART -- the CCD detector.
6.5 cm diam circle-- square inscribed in it.
Indexing, bravais lattice, real-time display (mwpc), etc.
Nice plotting tools (a la Minor) to analyze patterns.
Has a simulation tool for testing of strategy.
------------------------------------------------------------------------
Report of the Data-Acquisition GUI Working group
Thomas Earnest, LBL
Not able to decide on the question of whether there should be multiple vs
single windows. The goal should be to allow user to focus without having
superfluous windows
Vert. vs. horizontal orientation? No answer.
Leading user through process
But there are two classes of user, should have a choice
Might have a graphical flow-chart of the stage in the process.
At ALS there is a single terminal dedicated to describe status of optical
elements.
Possibility of tutorials -- put something on the WWW Actually work through
data-collection.
Strategy programs will be useful.
Major subdivisions
Check beamline -- current, alignment
Mount x-tal, check camera, gonio
Take test images and display
Index and check bravais lattice and laue group
Pick strategy
Collect data
Process
Balance between subjectivity and detail. Output from data-collection should
go straight into processing.
Archiving -- Keep data for 100 days at esrf! Users could process completely
so there's no need to keep on line.
Remote login for data reduction.
How about validation of quality control? Acquisition software needs to be
validated. Crucial because there's no second chance.
------------------------------------------------------------------------
Report of the Beamline-control working group
Carl Cork, LBL
Novice -- two buttons: align, set wavelength
Beamline control
No single standard for device control
No single std. for GUI interface
The group promises to search for a connection program that will facilitate
communications between GUIs and algorithmic (command-line-driven) programs.
Group will set up a mailer for communication.
------------------------------------------------------------------------
Report of the Image-file formats working group
Andy Howard, Molecular Simulations, Inc.
Conclusions.
File will have ascii header followed by binary data
Compression will be
encouraged
not required
defined later
Can we use gif, tiff, etc? Probably not -- this is all grey-scale
Header
1. ASCII values: keyword value
2. Maybe should follow HDF, and external standard. Out of court because we
want header to be ascii!!
3. CIF or CIF-like
4. Where CIF items are defined, use them.
5. Add our own CIF dictionary entries elsewhere.
Use multiples of 512 bytes -- look at end of each block to see if the header
is finished.
Contents of header
Obligatory:
entries necessary for processing
_# dimensions (2?)
_numb pixels in dim 1
_numb in dim2
_ number planes in third dim, etc.
_ data_type (in the binary part -- i*8, f(ieee), etc.
_ compression (none, type, ...)
Optional
Lots of stuff...
Source
lambda/E
bandwidth
Crystal goniostat
Labels on motors
Formal description of geometry -- use of vectorial representation
Values of these during the image
Detector(s) (Detector goniostat)
Detector geom phi, psi, omega, delx delz
Nonlinearity of position (spat. distor.)
Px dimensions
Sensitivity
Variations in sensitivity
Expt'l info
time stamp
symbol to describe where this image sits in the whole xpt.
expt:run:image
Maybe hdf will do -- check with ncsa.
------------------------------------------------------------------------
