Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.stecf.org/conferences/adass/adassVII/reprints/blym.ps.gz Äàòà èçìåíåíèÿ: Mon Jun 12 18:51:43 2006 Äàòà èíäåêñèðîâàíèÿ: Tue Oct 2 02:31:07 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: agn

Astronomical Data Analysis Software and Systems VII
ASP Conference Series, Vol. 145, 1998
R. Albrecht, R. N. Hook and H. A. Bushouse, e
Ö Copyright 1998 Astronomical Society of the Pacific. All rights reserved.
ds.
Mixing IRAF and Starlink Applications -- FIGARO under
IRAF
Martin J. Bly and Alan J. Chipperfield
Starlink Project 1,2 , Rutherford Appleton Laboratory, Chilton, DIDCOT,
Oxfordshire OX11 0QX, United Kingdom. Email: bly@star.rl.ac.uk,
ajc@star.rl.ac.uk
Abstract. The Starlink Project has introduced a scheme which allows
programs written for the Starlink Software Environment to be run in
the IRAF environment. Starlink applications can be controlled from the
IRAF CL, reading and writing IRAF .imh data files. Conversion to and
from the Starlink Extensible N­Dimensional Data Format (NDF) is done
on­the­fly, without the need for a separate data­conversion step. The
intention has been to make the Starlink applications appear as much like
native IRAF applications as possible, so that users can intermix tasks
from the two environments easily. The general­purpose data reduction
package FIGARO is now available to be run from the IRAF CL, and
more Starlink applications will follow in due course.
1. Introduction
Modern astronomical instruments demand flexible data­analysis facilities which
allow complex processing chains. Single packages, or sets of packages under one
environment, may not provide all the necessary steps or may not do specific
tasks as well as a package from another environment. However, the increased
sophistication of software has isolated users of one package from the facilities of
other packages.
Two ways to break down the barriers are:
. To enable applications from one system to be run from the user­interface
of another.
. To perform `on­the­fly' conversion of data formats.
A system has been developed to enable packages written for the Starlink
Software Environment to be run from the IRAF CL so that an IRAF user can mix
and match application tasks from the two environments as required to process
data, all under the control of the IRAF CL.
1 Managed by the Council for the Central Laboratory of the Research Councils on behalf of the
Particle Physics and Astronomy Research Council
2 http://star­www.rl.ac.uk/
177

178 Bly and Chipperfield
Figure 1 shows how the components of the Starlink/IRAF inter­operability
system fit together.
Figure 1. The Starlink/IRAF Inter­operability System.
2. The Message System Adaptor
At the heart of the system is the Message System Adaptor (Terrett 1996). IRAF
and the Starlink Software Environment have similar architectures whereby the
user­interface communicates with the task by means of messages. The user­
interface sends messages to control the task and the task replies with information
or requests for parameters etc. The Message System Adaptor is a Tcl script
which sits between the IRAF CL and the Starlink task, intercepting the messages
flowing between them and converting between IRAF CLIO protocol and Starlink
ADAM protocol. In this way the adaptor looks like an IRAF task to CL and
like a Starlink user­interface to the Starlink task.

Mixing IRAF and Starlink Applications -- FIGARO under IRAF 179
3. Data Conversion
Starlink packages use Starlink's Extensible N­Dimensional Data Format (NDF)
for data storage. The data access layer for programs is provided by the NDF
subroutine library, which has the built­in ability to use externally­provided data
conversion tasks to convert foreign data formats to and from the NDF format
`on the fly'. This facility is used, together with tasks from Starlink's CONVERT
package, to convert between NDF format and IRAF .imh or FITS format when
running from IRAF. There is no need for a separate data­conversion step in the
processing and the potential is there to handle many other data formats.
One pitfall with this system is that not all components of all NDFs have
equivalents in the other formats, so data may be lost in the conversion process.
This is particularly true of error estimate data, which are an intrinsic part of
the Starlink NDF design but are absent from the other formats.
4. The User's View
Tasks may be invoked and parameters set in the normal IRAF ways. The main
di#erences a user will see are:
. A Starlink­style graphics display is used by Starlink applications. Each
graphics application has a parameter defining the device to be used and,
if the device is `xwindows', a special Starlink window will be used.
. Starlink applications tend to have richer sets of parameters.
. More diagnostic messages appear in the event of errors.
5. Generic Package Definition
The Starlink Software Environment requires that application packages have an
associated Interface File, which defines the parameters of its applications, and
Package Definition Files which define the commands available and the source
of help etc. Other environments, such as IRAF, require similar information
presented in a di#erent way.
So that all the files required by various environments can be generated
from a single source, a generic package definition format, known as the Interface
Definition Format (IFD), has been developed. The format allows environment­
specific inclusion or exclusion of elements of the description, for example where
an application required in one environment is not relevant in another. Tcl scripts
have been written to process a package IFD file and produce the files required by
the Starlink and IRAF environments. The scheme could be extended for other
environments.
6. Availability
At present, the general purpose data reduction package FIGARO is the only
Starlink package in production use under the IRAF CL. More, including the

180 Bly and Chipperfield
kernel applications package KAPPA and the CCD data reduction package CCD­
PACK, will be available soon.
The software is freely available for non­profit research use on the Starlink
CD­ROM or from the Starlink Software Store at:
http://star­www.rl.ac.uk/cgi­store/storetop
Further information may be found in the Starlink documents:
. SUN/217 -- Running Starlink Applications from IRAF CL,
. SUN/220 -- IRAFFIG -- Figaro for IRAF,
. SSN/35 -- IRAFSTAR -- The IRAF/Starlink Inter­operability Infrastruc­
ture, and
. SSN/68 -- IFD -- Interface Definition Files.
7. Conclusions
This method of running packages designed for one environment from the user
interface of another works well and increases the range of procedures available
to users for data processing without the cost of writing new packages. Com­
ments from users have been favourable. The system could be expanded to cover
other environments, particularly where architectures and parameter systems are
similar.
Tcl is a powerful tool from which to build a protocol translation system and
language converters.
Following the release of the next batch of Starlink application packages
for use with IRAF we intend to monitor user reaction to the products before
embarking on further work in this area.
Acknowledgments. This work was done in the UK by the Starlink Project
at The Central Laboratory of the Research Councils and funded by the Particle
Physics and Astronomy Research Council. We are grateful for the contribution
of the IRAF Programming Group at NOAO in bringing this work to fruition.
References
Terrett, D. L. 1996, in ASP Conf. Ser., Vol. 101, Astronomical Data Analysis
Software and Systems V, ed. George H. Jacoby & Jeannette Barnes (San
Francisco: ASP), 255