[Date Prev][Date Next][Date Index]
Diffraction Issues ...
- Subject: Diffraction Issues ...
- From: jpq@radish.aps.anl.gov (John Quintana)
- Date: Fri, 13 May 94 15:15:56 CDT
Since sixteen people responded to my request for interest in diffraction
issues, I thought we would start the discussions on the beamline_controls
listserver and then see how it goes (we can always branch off onto another
listserver if we need to, the group is too large to try and deal with
email). If you currently are not subscribing to the listserver, send
email with no subject line or message to
listserv@aps.anl.gov
and you will receive instructions on how to join.
To start things off, I will try and distill some of the
conversations that I have had with people into demonstrative statements.
Feel free to blast away with them. Broadly,
the discussions I've had boil down into six areas.
1) Resources
2) Data Formats/Transfer
3) Mitch's Document
4) Software/Data Collection
5) Visualization
6) Super/Epics
1) Resources: Since resources are going to determine what we can and
can't ultimately do, I put this at the top of the list. Few CAT's can
afford to have a full time programmer on staff now and that is especially
true for operations. Consequently, the control software effort must
keep in mind CAT resources and have a definite end in mind. However,
while the resources of an individual CAT are relatively small, the resources
of the community at large is significant if we collaborate. Also, we
must do as little 'reinvention of the wheel' as possible and use tools
that the computer revolution has given us over the years. One approach would
be an iterative one where we take an existing command line program (e.g.
Super), and spruce it up with an embedded language/graphical interface
like tcl/tk and then spend our resources in phasing in capabilities
we want and 'transmogrifing' the program.
2) Mitch's Document: Since Mitch's work comes from primarily a diffraction
beamline, his document is extremely relevant to our effort. He has done
a good job in identifying the requirements of primarily a diffraction beamline
in terms of outlining a 'top down' approach. Mitch does a very good job
of outlining the basic functionality of what a crystallographic package
needs to do in terms of defining and moving in reciprocal space. Needs
for array storage in the data file format etc ....
of what is below will be reiterations or elaborations of what Mitch presented.
3) Software/Data Collection:
GUI vs. Command Line Interface: An easy to use graphical user
interface is preferred, but a command line interface is
required that has the capabilities of an embedded macro
language. Most beamline software packages do not have
an easy to use user interface. For example, spec and super
both use two to three letter commands which are no longer
acceptable if the application is build around an existing
macro language (several exist). The syntax should follow
a form similar to those used by most macro languages and follow
more or less a 'natural language'.
<command> <arg> <arg> <arg>
(e.g. scan theta 20 30 10 steps)
This approach is preferred over an 'object oriented' language since
a user typically wants to 'do something' (e.g. 'scan theta' as
opposed to 'theta scan'). The syntax also needs to be sensitive
to the fact that many users may not be familiar with reciprocal
space and the command language should not use terms which only
those who are 'guru's' will understand (A user shouldn't have to
know about reciprocal space concepts to perform a simple theta-two
theta scan).
EPICS: The EPICS tools are pretty (e.g. medm), but do not seem to be
well suited for dealing with control of the experiment (e.g.
no scan capability). Therefore epics tools should only be
used when necessary or convenient and are probably more suited
for 'non intelligent' operations such as looking at the position
of two theta but not (hkl). In addition, an alternate path should
be considered since the software may not be used in an EPICS
environment.
Programming Language: FORTRAN is not a suitable language for instrument
control. ANSI C and/or C++ should be used.
Graphics: Yes, online and be able to plot to hardcopy as well as screen.
User Devices: The concept within CONSOLE of giving the user simple
hooks in the macro language to manipulate his own hardware is
very attractive. The programmer shouldn't have to get involved
for very simple 'unforeseen' additions to the system.
Expandable: Software must be expandable in an easy well defined manner.
Demonstration Ports: The current work on SUPER/EPICS and TCL have
shown the viability of EPICS as the hardware interface for
beamlines. These demonstrations have shown that EPICS goes
a long way to standardizing software
but its time to 'move on the real thing' whatever that is.
Sitting on the APS floor and seeing the magnets being installed
through the opening in the ratchet door makes me realize that
beam will be coming very soon.
4) Data Formats/Transfer: This is a subject where one is preaching to
the converted, but without doubt, the community is crying for
some kind of data format standard. In fact, it has reached the
point where a 'bad standard' is better than no standard at all.
I perceive that the problem is one of implementation rather than
specification. However, starting with:
Specification:
1) Definitions: We have the International Tables
and the IUCr for the basic definitions. We should use them
(at least in the data file) and data should be stored in
terms of these definitions. If the IUCr definitions are not
used, then annotations to what are used must be in each data
file stored and should be obscure enough to not confuse the
user.
2) Utilities: Utilities must be provided to convert the
data to a flat ascii file, and to some other 'standard
formats'. A library of utilities will be created since
conversion utilities will be created on a case by case
basis for different formats.
3) Platforms: UNIX, VAX, PC, Mac, you name it....
4) Physical Format: Unimportant provided that the format
is binary and routines exist to access the data via keyword
etc... on any platform.
5) Specification should include definitions for standard set
of experiments such as Crystallography, Reciprocal Space
Volumes, Powder Diffraction, DAFS.
6) Intelligence: Format should include keys for what the
relevant independent and dependent variables are so that
plotting programs can key off of them to give the user a
plot which makes sense.
7) Stored data can include: Raw Data, Cooked Data (e.g.
converted to absolute units with deadtime etc... taken out),
of Parboiled (e.g. only deadtime correction done).
8) Format and Utilities must be in the Public Domain
Implementation:
This is always the hard part (converting all those great
ideas into code). The cost of implementation can be
greatly reduced if an existing general file specification
is used (e.g. HDF) Jon Tischler has some ideas on this.
5) Visualization: The control software should not try and perform every
possible task. However it must interface with other packages
including visualization tools such as PV-wave, IDL, Khoros, Spyglass,
etc....
6) Super/EPICS: BESSR CAT has been using this program and there experience
seems to be that it is currently unstable from a user's perspective.
At times Super seems to be unaware that EPICS has hit a limit
and the MEDM screen sometimes aborts when the mouse button is
trying to minimize it. Super/EPICS in its current form is too
'spec-like' (i.e. no GUI and two letter commands)
I hope there is enough here to start discussion
- John
--
John Quintana Internet email: jpq@nwu.edu
DND-CAT Synchrotron Research Center Voice Phone: (708) 252-0223
APS/ANL Sector 5, Bldg. 400 FAX Phone: (708) 252-0226
9700 South Cass Avenue
Argonne, Illinois 60439