[Date Prev][Date Next][Date Index]
Re: Diffraction Issues ...
original email is indented.
comments from Karen Coulter are denoted KC>.
replies from John Quintana are JQ>.
>
> 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.
KC> (John - I put some comments below, couldn't decide if I should put them here,
KC> or at the end.)
>
> 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.
KC> The EPICS sequencer program might be quite well-suited to more complicated
KC> control functions such as performing a (theta-two-theta) scan. I believe
KC> that a library of 'diffraction activities' could be defined and implemented
KC> in a sophisticated and easy to use manner, by building on (and improving)
KC> some of the tools that are already in EPICS, rather than re-inventing the
KC> wheel. I think Mark Rivers has demonstrated how straightforward it is to
KC> do scans in IDL thru the EPICS channel access library for IDL. It was my
KC> understanding from the workshop discussions that EPICS is to be the hardware
KC> interface mechanism for all instrumentation, so I don't understand what it
KC> means to be outside an EPICS environment.
JQ> Unfortunately, this is a topic that I have to be a bit sensitive to. In order
JQ> to properly train my users before arriving at the synchrotron, it will be
JQ> necessary to try and get working models of the control software on platforms
JQ> where EPICS doesn't and probably never will run. Beamline specific
JQ> considerations (such as monitoring of vacuum systems, slits etc...) can
JQ> easily be handled by MEDM. However, I personally feel that the device support
JQ> layer to motors etc... should be through a separate layer so that other
JQ> hardware can be accomodated in a straightforward way. EPICS certainly
JQ> will be used at the APS, but if the code is transported to another institution
JQ> it must be portable enough to survive without EPICS and its tools.
KC> Perhaps this is a semantics problem, (which is a problem for just about
KC> everybody when having a discussion about 'EPICS'). It is true that MEDM
KC> is NOT intelligent about data content, thereby making it extremely
KC> flexible for looking at any kind of data in any format. However, that
KC> does mean that it won't do any kind of data processing, even something as
KC> simple as normalizing a data point or displaying the ratio of two data pts.
KC> Any kind of processing must be already done in database records in the IOC.
KC> But this is a characteristic of MEDM, not of using EPICS. The solution is
KC> not to make MEDM an enormous data processing program or to write a new tool,
KC> but to exploit the programs that do data processing well (PvWave, IDL, other
KC> existing beamline programs, etc) and give them efficient access to the data.
KC> But this is still what I would consider an EPICS environment.
JQ> I agree, we are just arguing semantics here. To me, EPICS comes in at the
JQ> hardware level. Going directly from the IOC to and MEDM screen breaks
JQ> a layer model since if EPICS is not used, neither can MEDM. Let me reiterate
JQ> that EPICS will be used at the APS. I don't believe this is really a
JQ> question anymore; however, certain CAT's must take into consideration
JQ> the possibility or eventuality that the basic software might be ported
JQ> to other systems.
>
> Programming Language: FORTRAN is not a suitable language for instrument
> control. ANSI C and/or C++ should be used.
KC> What about all these macro languages?
JQ> This comment is more historical than anything else. There are many programs
JQ> out there still written in FORTRAN (DAS is one of them). Its just the
JQ> wrong language for the compiled part of the program.
>
> Graphics: Yes, online and be able to plot to hardcopy as well as screen.
KC> Anything displayed on a screen under X Windows can be dumped to a hard
KC> copy. Applications that generate screen graphics should also be able to
KC> generate postscript. Any other hardcopy capability should be implemented on
KC> an OS basis, and not on an application by application basis (but applications
KC> must NOT preclude making hard copies thru typical OS methods). Using
KC> programs like IDL and PvWave take care of this for us.
>
> 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.
KC> Unless there are insurmountable problems with applying HDF (CDF, netCDF etc)
KC> to our anticipated experimental data, I don't see how we could possibly opt
KC> for starting from scratch and expect do any better. A 'bad' standard that
KC> uses up development resources and isn't any better than what already exists,
KC> is as bad as (worse than?) no standard at all.
>
> 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....
KC> Shouldn't the software actually BE these packages, using the best features
KC> of each?
JQ> It depends on what part of the package is to be completely stand alone.
JQ> One can easily incorporate simple on-line graphics and then leave the
JQ> fancy imaging stuff to a separate third party program. The idea here
JQ> again is portability.
>
> 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)
KC> Does this mean BESSR CAT is abandoning Super/EPICS? Is there something
KC> inherently wrong with the approach, or is it a matter of the integration
KC> being immature? Are they trying to fix it and having problems making
KC> it work?
JQ> My intent here was only to reiterate comments
JQ> about the current state of diffraction software using EPICS. Taking this
JQ> as a starting point we can decide on where we want to go. For example, if
JQ> the basic philosophy behind Super makes it difficult to turn into something
JQ> we really want, then we should devote our resources to something that will.
>
>
> I hope there is enough here to start discussion
>
> - John
>
>
>
KC> (comments referred to above)
KC> One shortfall of the top-down approach is that it assumes that one knows
KC> what the final product must be from the start. It tends to lead to large
KC> monolithic programs which become inflexible over time. I think Mitch's doc
KC> is a great start at organizing the requirements and actually getting something
KC> down on paper, but I don't think the top-down approach translates well into
KC> program development and prototyping. (sorry...I don't want to debate
KC> the virtues of top-down, bottom-up, inside-out, whatever). Perhaps Mitch's
KC> doc and any additional requirements could be reviewed to see at what layers
KC> different levels of abstraction can be applied. do we need another level
KC> of abstraction above the epics/channel access layer? are there certain
KC> activities that several applications can share? What programs already exist
KC> that satisfy the requirements for a given activity and do these things well?
KC> Can 'the best' features of existing programs be pulled out to create
KC> independent modules? If so, how do they all talk to each other? What are
KC> the pros and cons of having all capabilities bundled together vs assembled
KC> module by module?
>
> --
> 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
>
----- End Included Message -----