[Date Prev][Date Next][Date Index]
Re: Diffraction Issues ...
> 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.
I think this is the best approach.
> 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).
I don't think the number of letters in command names is particularly
relevant. The problem is that current command-line driven programs
require the user to know too many commands. We should offload as many
functions onto EPICS (e.g., use EPICS/medm to set motor parameters).
From the user's viewpoint, the result is a much smaller command set.
If several diffraction programs are treated in this manner, the user
will see much less difference between them, so the software we get is
not only easier to use, but also more similar from beamline to
beamline (assuming different beamlines use different programs).
> 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.
The absence of scan capability says little about the nature of the virtual
motions that should be implemented in EPICS. I would argue that complex
motions of several motors be implemented in EPICS where possible, so that
custom software does not have to do it. Reciprocal space may be an exception.
BTW, Ned Arnold (nda@aps.anl.gov) has prototyped a scan record for EPICS.
It's quite impressive already, and I hope a demonstration can be done at
the APS User's Meeting.
> Programming Language: FORTRAN is not a suitable language for instrument
> control. ANSI C and/or C++ should be used.
Ok by me.
> Graphics: Yes, online and be able to plot to hardcopy as well as screen.
Absolutely.
> 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.
I think the 'real thing' will turn out to be a continually evolving set of
custom programs. If so, we already have an early (and unacceptably primitive)
version of the real thing.
> 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 agree. However, the choice we make now will be with us for a long time.
> 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.
I suggest something similar to the Software Tools archiver format as
the flat ascii file format. This would allow collections of data files
to be manipulated and plotted on any machine (portable versions of the
archiver exist) to without loss of the ability to extract single data
files. This would not be a substitute for something like HDF, of course,
but HDF might be easier to accept if a standard flat, editable derivative
were available.
> 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)
The MEDM problem has been fixed, but there are more problems with this
program. It's clear that one eventually would like a program that takes
better advantage of the fact that it's talking to EPICS.
> 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
>