Aae:ff HH $ dR- HHHHff@d' )Footnote TableFootnote** . / - :;,.!?1 \[!  ]hLOT TableTitleLOFFigureTOC1Heading2Headingn *tools-dir*BourneBrutvan CRremoval CRremovalsDraco:*default Draco:SamplesDraco:Samples;NOAODraco:Samples;dataDraco:Samples;fileDraco:Samples;findDraco:Samples;ut Draco:Tools Draco:define Draco:makeDread:*default Dread:define Dread:makeGEISreporterkeywordsGeddis GillilandGinsbergGladwellGoddardHSTsHanischsHubbleIRAFsKant KantrowitzsLucksMandelMeta MetaobjectMetapplicationOopsSeptSynphotZViterbi2csortedcalibccdproc+ccdredcentredchecksumckvoclcmd deconvolutionMdefi defconstant definedataedefinedataformatdefinefiletypedefinepackagedefine-ckv-reporterdefine-fkv-reporter defsystemdevdirHfsortedfilesfindlikeimagesfkv flatcombinefnfwy geis-reportergeis-reporter-keywordsibidimredin[IRAFirafxlogoutmakeinventorys make:*central make:load mboxmetrics namespacenewlineanoaooption=\crrejectpathname pathnamespheadipushnewipDracoo pDraco:apsb recognizers rmrptlsh spectra:startcstrfitststsci:stsdas substringssubtypessuperset test:startuparmp usedqf=\yesusrpvoliwfpcxdimtogf=\\yesrxdimtogf=\\yes: xdimtogf=yesa zerocombinef   EquationVariablesKa s /j a l tm atio Sep otZr 2s cau prov dx chy kvo{  | tio~  de  tae Idat Ode Uty ep efi por Rine rte Xste di ted fi mag  fl   ge er por rds mre AF lo ei s tra loa me ame ewl o crr U u _ U na V ph W pu X  Y oo Z ac [  \ iz ] rm ^  ` ec a ar b rf c st e st g su h gs j yp l pe m te <$marker1>rp <$marker2>to <$paratext[Title]>s: <$paratext[3Heading,1Heading]> <$curpagenum><$lastpagenum><$monthname> <$daynum>, <$year> (Continued)+ (Sheet <$tblsheetnum> of <$tblsheetcount>)/Pagepage<$pagenum>mHeading & Page <$paratext> on page<$pagenum>caSection & Page%Section<$paranum> on page<$pagenum> See Heading & Page%See <$paratext> on page<$pagenum>. Table & Page'Table<$paranumonly> on page<$pagenum> Figure & Pagee(Figure<$paranumonly> on page<$pagenum> <$daynum> <$monthname> <$year><$monthname> <$daynum>, <$year> ! $l CCQKeywordsl DDPloal EEQewlKeywordsl GU Aal PooAl P^ l Pst l Pl Ael P mal P l $paAel  cul enul ``Q>, Ael bbP+Shl eePeetunl ffQm>mAl hhP> pl kkP & gel mmP<$pNumberl Parl ssPTal Ply>TOCagel PgeeLOFurel PenuLOTl QyeaIXl P>, Ael PlTitleCl PAuthorsDl PRevisionl PGl nnPAl PNumberl PTitlel PPAuthorsAel P Revision  W U X Z X U ;u     u G   U  P3.0     @  Q5.0 ) K A BP 9 =m Ku $ - 0 1P 2   CO . / 3 4 5O 6 7 8 "P  1.0  7.0     OD8.1 "P  i       "P O6.2 ; * ; :i6.1.1 ;P "r K ; ; ;U ;X :Z6.1.7 O6.1 ;u ; ;u " * " "P ; " " " " H FIGURE 1.   A *B &9 = %K $ UP 0 '1 &2 %  *C ". "/ "3 "4 "5 "6 "7 "8 "" "  * " "  "  :O6.1.4 ;P :i6.1.3 *     "" *O ;    4.0 *: *. ;P!  r"  8.0# ;$ ;% =& "' "( "O) "* "+ ", ;- O7.2. K"/  "0 ;;1 !"2 ""3 ""4 ""5 :H6.1.56   7  *8  &9 ": "%; "< "U= "> "'? ;&@ "%A !;*B "O"8.2C #O7.1D $="E %;"F &""G ':"6.1.6H (;I )"J *"K +"L ,"M -"N ."O /;P 0;;Q 1":R 2".S 3" T 4" U 5;"V 6"OW 7;X 8"Y 9"Z :"[ ;;\ <K ] =;!^ >;"_ ?"` @"a A;b B;c C=d DKe EKOf FKg GKh H;i IKj JKk K .l L*/m M 0n N 1o O;2p P"3q Q 4r R"5s S"t T" u U" v V" w W "x X*"y Y*"z Z*"{ [*"| \*"} ]*;~ ^*" _*; ` O a  b  c = d*; e*" f*: g*. h* i* j* k* l* m* n* o* p*; q*: rO.7.3 sKT t U uKV vKW w"X x=Y yKZ z:[6.1.8 {  |* }; ~" " " ;   ; " * K *   ; K " K K K K K   "   K A B K A BU = K A B   " :6.1.2  =6.0 "   " "   ; = " " " " " " " " "T "U "V "W "X "Y "Z "[ " " " " * " * * * * * * * * * * * * G * * * M     * *        2.0 " " " " " " " " "  "     "AwdA`e"dB"fkR CDl R ` m "l6 DCl l6 ` m" Keywords: R E R ` mdata analysis, data reduction d FGG*HH GF HHOOL -` q Wherefore Art Thou Draco? )UU Kn pData reduction and analysis are time-consuming tasks that often require substantial knowledge of mundane things 5UU Kn"xlike tape drives, data formats, and data analysis systems. From a computational perspective, there is little difference AUU Knbetween reduction and analysis so we will let zanalysisn abbreviate analysis and/or reduction.  From our perspective, MUU Knqit would also appear that there is little difference between analyzing data and using numerical methods to solve YUU@ Kn fmathematical problems. To illustrate this second point, let us re-use the introduction to [Reid90]: kUU Mn aFor many years, developers of scientific software worked independently on finding algorithms and wUU Mnlsolutions, many of which were highly machine dependent. This practice had n and all too often still UU Mnihas n many drawbacks, the most obvious being time wastage and duplication of effort. In the late iUU Mnng]sixties and early seventies this fragmented approach began to give way to re-usable software tUU Mnor_components, usually in the form of routine libraries. These libraries encapsulated algorithmic AUU Mnbecdesign in a portable, reliable and re-usable form, becoming increasingly diverse and comprehensive UU Mniveas they grew. As a result of this comprehensiveness, the selection of appropriate algorithms and the nUU@ Mnme=parameters for driving these algorithms became more complex. ˪UU` Nnco pתUU Qnse]Although these software components were welcomed, a growing body of scientists and engineers s㪛UU Qnep`became increasingly frustrated with using programming languages rather than abstract scientific hi漢UU Qn p^concepts. The result was a growing gulf between the needs of the user and the manner in which UU@ Qnussolutions were presented. UU` `n I hUU anUUXEarly attempts to bridge this gulf centred around software packages aimed at particular blUU an\communities. This approach is still in use today, but while it frees the user from computer ed+UU anelanguages, most package [sic] have inherent limitations. The most notable limitations are: having to c7UU an`learn a new command language; restriction on the algorithmic solutions available; inter-package e CUU an nbincompatibility; and limited on-line assistance. Early enhancements include graphical output, and OUU anUUcfor the more sophisticated packages, graphical interaction. However, whilst the package has raised s s[UU anepgthe level of abstraction at which the user can apply algorithms, it has, in general, failed to achieve gUU@ anepUthe objective of providing easy-to-use problem solvers for engineers and scientists. UU nusrReid might as well have been describing the state of data analysis in 1993. In [Reid90] he proposes to attack the UU nacnproblem with knowledge-based systems, an approach that has had some success. For example, [Lucks92] describes UU nomjan expert system for selecting the appropriate numerical method from the NAG (Numerical Algorithms Group) UU@ navmLibrary, and [Johnston87] describes a prototype expert system for reducing CCD (Charge-Coupled Device) data. UU noHowever, there are very real differences between Reids problem domain and ours. Given a mathematical problem, nd ǪUU nUUsthere are formal metrics for determining its attributes, and given a set of problem attributes, numerical analysis aӪUU n avexperts tend to agree on which algorithms are most appropriate. Contrast this state of affairs with astronomical data ߪUU nngvanalysis where formal metrics are rare and the experts often disagree. For example, there are at least five different 몇UU na valgorithms for removing cosmic ray hits and at least five image restoration algorithms that attempt to compensate for UU nadkthe Hubble Space Telescope spherical aberration. An astronomer needs to experiment with different analysis oprUU nhoqtechniques, and we presume that other disciplines require this sort of experimentation as well. We are forced to xUU@ nduPconclude that Johnstons success was largely due to his systems limited scope. er'UU n bsIgnoring algorithmic issues, current work on astronomical data analysis focuses on interactive data analysis, e.g. s f3UU n ak[Graham92, Mandel93]. Data analysis is clearly an important task and is often complex enough to warrant an ag?UU nituinteractive approach, but analysis has many facets. We contend that the potentially high volumes of data force us to rKUU nreolook for systems that can perform their duties while the user is performing more gratifying tasks. We would be forWUU nPtmaking a serious mistake if we continue to focus exclusively on interactive data analysis. A more balanced approach paH HtnJJnt 1Heading Rule H IS sH T e ` xim&They are actually Common Lisp macros.  JHsy d tdKiLL creHHLK eHHGN )UU nhavis needed and the only alternative is batch processing. This might seem hopelessly out-of-date at first, but when one UU nap}considers the alternative, namely interactively, i.e. {manuallyn, reducing large amounts of data, it should seem quite oUU@ nt reasonable if not desirable. t6UU ninmWe also contend that the world does not need another data analysis system. A number of analysis systems have eBUU nraralready earned the respect of the scientific community so there is no reason to develop another one. For example, NUU noIRAF (Image Reduction and Analysis Facility) has become a fixture in the astronomy community and it is safe to y aZUU n Lwassume that other analysis systems have also acquired official or quasi-official status in other research communities. KfUU nsUnfortunately, new users of these systems often suffer considerably before producing the results they desire. Even rUU nissseasoned users have bad days now and then, or are forced to learn a new system because it provides a missing piece ~UU@ ncoof functionality. UU nctxIn a perfect world there might only be one analysis system or, more precisely, a single analysis system user interface. t UU nsAs it happens, we already have proven technology capable of realizing this vision. The key to creating a universal haUU n user interface is first ensuring that each analysis system provides a machine interface, e.g. via Unixn sockets or some UUUU naglother communications protocol. The very popular client-server architecture would not only enable users with ƪUU nmetrelatively inexpensive terminals or workstations to connect to more powerful analysis servers, it would also enable ҪUU@ nUnLpeople to write novel clients like the universal interface envisioned here. ciꪚUU ny oLet us digress briefly by describing a second, unrelated novel client. Synphot is a package in STSDAS (Space temUU nesjTelescope Science Data Analysis System) that enables astronomers to simulate HST (Hubble Space Telescope) UU nnamphotometry. This would clearly be a useful tool to an astronomer planning a set of observations. An observer ,UU nrotcurrently uses a proposal editor to create (modify) a specification of the observation plan. Suppose STSDAS, or its ceUU n toparent system IRAF, provided a machine interface. Then the proposal editor could provide Synphot functionality nag&UU niolsimply by connecting to an STSDAS/IRAF server. The server would not require modification because the editor me2UU nenuwould just be another client. So here we have a second potential application in search of an analysis system machine n>UU@ nno interface. ikeVUU nerpLet us digress again by pretending for a moment that all analysis systems are equipped with machine interfaces. enbUU ncklThese interfaces could presumably be categorized according to the standard communications protocols used to tnUU nbbgimplement them. Given this state of affairs, how would our universal interface work? We would begin by r pzUU nbslrepresenting each system with a structure describing its machine interface, its native data format, and the ioUU nonsfunctionality it offers. The user would specify an analysis task at a high level and the interface would select an osaUU nviuanalysis server based on the functionality desired. The data would be converted to another format if necessary and a eUU n bwrequest would be submitted to the selected server. The user would then wait for a result to be returned (this might be seUU ns wan error report) or work on something else. If the analysis is particularly time-consuming, notification of the result thUU@ nst=might be transmitted via electronic mail or even voice mail. kΪUU n cmUnfortunately, the assumption we made during our last digression is blatantly false. Analysis system machine bڪUU nGivinterfaces, if they exist at all, are extremely rare commodities, and for good reason. Until recently analysis system 檇UU nh rdevelopers had virtually no incentive to develop machine interfaces. Without a second system to communicate with, UU nr wit made perfect sense to expend all resources on the (interactive) user interface and on algorithms. At this point, we baUU nnatmust emphasize that this resource allocation strategy is no longer sensible. Machine interfaces are not just a good s UU@ nle*idea, they are a good idea ztodayn. "UU` nne t:UU` n dMoNNnasiHHNM iHHLQ #t ` q eWhat Is Draco? ev)UU npDraco is a software system and an experiment. The system is designed to act as an intermediary between analysis st5UU nqsystem users and their analysis systems by issuing the appropriate user interface commands. The experiment is to AUU ntuse this system to see how well or how poorly such an approach can work. (In the previous section we argued for the unMUU nydesirability of machine interfaces, in addition to user interfaces. If machine interfaces existed, we would have layered pYUU@ ngDraco on them. As the command-line user interface is the common denominator, we have built upon that.) aceqUU noo}In the scenario we have in mind, the scientist gives Draco a specification of thedata, e.g. a set of files, and a high-level }UU nodescription of the analysis steps desired. This high-level description must not refer to specific data formats UU nsand/or analysis systems. We want to enable scientists to focus on science not on software. Somehow, Draco must use deUU nn wits knowledge of the users analysis software to translate this high-level description into a sequence of instructions useUU ndsnthat will bring about the desired transformation(s). We will assume that the knowledge needed to perform this UU@ nviQtranslation can be encoded by experts and then shared by Draco users everywhere. fŪUU ntonOur design depends on the following observation: purely syntactic manipulations are often quite useful. Draco ѪUU nsencan be likened to an algebra. The analysis expert defines primitives and may combine them to form procedures. ݪUU nentThe translation of high-level descriptions to actual analysis system instructions is done on a per-primitive basis. of骜UU ns kDraco does not know anything about the semantics of the primitives, but it does know which combinations of anaUU nwatprimitives are syntactically valid. The people who define the procedures are responsible for ensuring that they are leUU nanwactually useful, and if they are syntactically valid, their successful translation is assured. This reliance on syntax ll  UU@ nsiLenables even nonexpert users to create procedures from existing primitives. s %UU nvioA second task for Draco is monitoring the execution of the generated instructions, but let us not get ahead of ign1UU@ nllXourselves. The key question remains: How feasible is this scenario today? We shall see. UUU` qikWhat Draco Is Not wUU nt yDraco is not (yet) a friendly system. Paradoxically, although it is a prototype of a universal analysis interface, Draco sUU ns zis not easy to use. This unfriendliness is largely due to the fact that we concentrated our efforts on the inner workings UU nesrof Draco rather than the interface. Draco is implemented in Common Lisp.  We evaluated two Lisp user interface UU nuresystems: Garnet and Common Lisp Interface Manager (CLIM). Both of these systems had startup costs or sUU@ n, Mdisadvantages which made us decide to concentrate on the internals of Draco. UUU nevsThe Draco prototype is also unfriendly to the experts who must encode the knowledge needed to translate the users mon˪UU niouhigh-level descriptions of analysis steps. We have not provided the expert with a knowledge representation language. nתUU n tlThis knowledge must be encoded as Common Lisp. There is a silver lining in this cloud: if one cannot encode (㪎UU nsttknowledge in Common Lisp, it is unlikely that one will be able to encode it in zanyn knowledge representation as揄UU@ nriClanguage. We have thus given ourselves the best chance to succeed. on` qs Draco Entities nes5UU nthwDraco has nine public entity types: converter, data type, file type, implementation, initialization file, KV-reporter, temAUU@ nonCpackage, primitive, and procedure. We briefly introduce them here. ts HOF cHG ls CxsAt some stage the reduction steps get replaced by analysis steps, but the dividing line is not well defined. th@ Cx([Gilliland92]). ldPeQQrtitHHQP HHNT %edUU nhe|A {proceduren or procedural primitive encapsulates one or more primitives. It may be viewed as a program schema, e.g. t UU no uremove bias and dark counts, then flatten and extract spectra. Draco translates a procedures primitives into data-sUU@ nd.ospecific executable scripts and invokes these scripts. We provide one built-in procedure: sanity-testn. dat6UU Wn i|A {primitiven represents tasks like remove bias counts or extract spectra. Primitives are defined in terms of the ucBUU Wntabstract data types they manipulate, but independently of the users analysis systems and data formats. A primitive sNUU@ Wnnbmay be associated with several implementations, e.g. one for each of the users analysis systems. fUU nanqAn {implementationn represents a Common Lisp function responsible for generating data-specific code for an rUU nqexecutable script. Implementations are defined in terms of the file types they manipulate and must be associated o~UU@ nvewith a single primitive. oUU nt }A zdata typen might be something like calibrated image. One may think of it as an abstract file type, but data types sUU nwmay eventually represent other types of data as well, e.g. status codes. Each data type may be associated with several n.UU@ n Wfile types, e.g. if the user is using several data formats. We provide two built-in data types: data-setn and scriptn. ƪUU nab~A {file typen is defined by its recognizer, a Common Lisp function or a Unix executable. File types are hierarchically ҪUU nssworganized, usually into a single tree whose root is the built-in Unix file type. A file type, especially one that has emeުUU nenksubtypes, may denote a data format. For example, the IRAF (Image Reduction and Analysis Facility) analysis bleꪛUU natisystems NOAO (National Optical Astronomy Observatories) package manipulates data files in OIF (Old IRAF iUU nivwFormat) format. These files include raw data, calibration data, and the calibrated images. The user may need to define actUU ntaxseparate file types for the various kinds of OIF files delivered, but may still find a generic OIF file type useful. We beUU@ nev^provide three built-in file types: directoryn, shell-scriptn, and Unixn. &UU ndazA {convertern represents a data format conversion program, i.e. a program that can read files of one type and write 2UU@ n orequivalent files of a second type. Data-format conversion functionality is not implemented at this time, however. JUU nt-zKeyword-value (KV) files are an interesting special case. Draco enables one to define {KV-reportern entities. These VUU nmatdefinitions are compiled into Common Lisp functions that extract the desired KV pairs from files of the appropriate atbUU@ niptype. zUU` nOlgAnalysis systems are represented by {packagen entities. A package may have a native data format. ibrUU nseDraco is initialized by specifying a set of {initialization filen entities. These identify files in the users file system. Two UU n uyinitialization files are automatically loaded if they exist, one in the users home directory and one in the users data UU n directory. The default name for these initialization files is .Draco.lispn. Any conflicting definitions are resolved in the UU@ nvahome directorys favor. e.ΪUU nrs|There are also a number of internal entity types. One worth mentioning is the zfile-datumn which is sometimes used by spڪUU nenwexperts when coding implementations. A file-datum instance allows Draco to keep track of a files attributes, e.g. its unc檋UU@ n t file-type. pa ` qth(Installing, Invoking, and Testing Draco . ,UU nOloIn this document, file pathnames are given using Common Lisps logical pathname syntax ([Steele90]). We assume 8UU no pthat you are running a version of Allegro Common Lisp that supports logical pathnames and that the logical host e DUU sDracon is defined so that it translates to the Draco source directory. (Consult your Allegro Common Lisp system n tPUU@ n2administrator or the Allegro Common Lisp manual.) H!RXY H!Z in xUUtThe reasons for not having f-sorted keyword-value reporters sort their report entries: (1) this design is easier to me xzrimplement, (2) sorting takes time, and (3) for any given keyword-value data file format, the order of the keyword-@ xac1value pairs often remains constant across files. cdSTTngInHHTS HHIIQW $enUU nsvAny user-supplied programs should be installed in Draco:Toolsn. Once you have installed your tools, enter your UU nrtrAllegro Common Lisp environment, load Mark Kantrowitzs defsystemn utility (if necessary), and execute the UU@ nirfollowing forms: u/` is/(pushnew#pDraco:make:*central-registry*) r t:` LiA(pushnew#pDraco:apsb-utilitiesmake:*central-registry*)p RUU nZ{These may be placed in your Allegro Common Lisp initialization file. You may now use the defsystemn utility to load (1)^UU@ n Draco, e.g.: o` em5(make:load-system%Draco:compile-during-loadt) oUU n flYour Lisp environment will now accept Draco commands. Draco assumes that the current directory is your data UU@ nudirectory. If you wish to change data directories, you must use the Draco function set-data-directoryn, e.g.: ` *(set-data-directory/big/disk/my/data) UU tnedpYou may now invoke the built-in sanity test. This test generates a brief summary of the contents of one or more enȪUU tnrk~directories. sanity-testn needs to create files in its input directories, so make sure you have sufficient file access ԪUU@ tnDNprivileges. This is how one invokes the sanity test on the current directory: ` wp:*&(sanity-test:start(#pp.))  ` q pAn Extended Example Co1UU` zaDefining Draco Entities tIUU( nnhDraco provides a set of functions  for defining or specifying Draco entities. Each function is named :cUUU wdefinen-zn, e.g. definefiletypen. All instances of a given entity type must be uniquely is aUU nanamed. Names are Common Lisp symbols and are assigned via the :namen keyword. An optional mUU y_:documentationn string may also be specified. All code for this example may be found in the pYoyUU@ heDraco:Samplesn directory. tUU`  sInitialization Files oUU nIThe Draco definitions for this example are distributed among a number of UU nie^initialization files that reside in Draco:Samplesn. Initialization file directives are ªUU ntyMactually Common Lisp forms, i.e. initialization files are just Common Lisp ΪUU@ nsource files. 檕UU HnCoSThe users initialization files are usually loaded by declaring them in either the a sUU HnXusers home directory initialization file or in the data directory initialization file. deUU HntyTFor example, our sample data directorys initialization file contains the following e  UU@ Hn directive: ana` mo(define-initialization-file d &` n(:fileDraco:Samples;file-types.lisp y1` n,:documentationfile type specifications is<` un:load-immediatelyt G` mp) HU aH o  xxisCode for processing the tilde directives ~inx and ~outx is in place and is fully tested (for historical reasons), al@ xxti5but Draco these directives are unused at the moment. mdVoWW HHWV sHHTZ 3y UU neiPInitialization files are loaded on an as-needed basis by default. There are two thUU nni[exceptions. The first is illustrated by the above example. If :load-immediatelyn is tioUU e Xniln or left unspecified, the declared initialization file will be loaded at Dracos on*UU nOconvenience. In this example, Draco will load the named initialization file as ent6UU@ nspEsoon as it has created the corresponding initialization file entity. NUU nXDraco will reload an initialization file if it discovers that it was modified since the ZUU n fSlast time it was loaded and this behavior leads us to our second exception. If the llyfUU nriMdata directorys initialization file is modified or if the user changes data trUU nXdirectories, the users home directory initialization file will be reloaded so that its ~UU nUdefinitions will take precedence over the data directory initialization files. Note aUU n-nVthat the initialization files declared in the home directory initialization file will UU@ zabgnotn be reloaded unless they were specified with a non-niln :load-immediatelyn value. claUU n fOOur sample users home directory initialization file is assumed to contain the e, UU@ ne following directives: ` pUU(define-initialization-file ed` p i(:fileDraco:Samples;converters.lisp ` pel,:documentationconverter specifications t ` pnc) ` Sp (define-initialization-file an` pad(:fileDraco:Samples;data-types.lisp  ` pda,:documentationdata type specifications o` pge) #` p (define-initialization-file ho.` pal-:fileDraco:Samples;implementations.lisp 9` pde1:documentationimplementation specifications oD` pfi) O` pUU(define-initialization-file ioZ` pn &:fileDraco:Samples;packages.lisp e` p *:documentationpackage specifications p` pn-) {` pim(define-initialization-file ` psa(:fileDraco:Samples;primitives.lisp fi` pon,:documentationprimitive specifications re` p) ` pia(define-initialization-file ` pco(:fileDraco:Samples;procedures.lisp ` pio7:documentationprocedural primitive specifications ` p(d) ` pil n` pad(define-initialization-file ty` p,:fileDraco:Samples;NOAO-calibrate.lisp if` p.:documentationsample implementation code ` pho)  ` p:(define-initialization-file at` p*:fileDraco:Samples;NOAO-extract.lisp  ` p o.:documentationsample implementation code +` pon) 6` p (define-initialization-file acA` p$:fileDraco:Samples;ut-obs.lisp e L` p1:documentationneeded by NOAO-calibrate.lisp nW` p) HXRY iHZ nt xspwDraco also enables expert users to supply their own default reporters. See the parameters Draco:*default-reporter* D@ xduRand Draco:*default-reporter-type*x in Documents/def-reporter.lispx. dYZZ HHZY HHXRW\ %brUU` File Types and KV-Reporters UU nioQThe file type is often the first Draco entity encountered. The user (or analysis t+UU nWexpert) should define all file types of interest. File types are organized as a forest e i7UU n Qof trees. We have provided a tree whose root is the built-in file type Unix and CUU@ nle5suggest that all file types be placed in this tree. :[UU nedXEach file type is associated with a zrecognizern which takes one argument, a file gUU nGname. A recognizer can either be a Common Lisp pathname naming a Unix expsUU ny Mcommand, e.g. a shell script, or a Lisp symbol naming a function. Recognizer DUU nduOcommands must print a string describing the file on the standard output stream . UU nQwhen they succeed, i.e. when the file is of the appropriate type, and must print UU nRnothing when the file is not of the appropriate type. Recognizer functions return UU@ nUUQa string describing the file when they succeed and otherwise return niln. nUU nUURThe user is encouraged to make every effort to provide recognizers that literally ǪUU nUUPopen and read files rather than rely (solely) on file-naming conventions. Draco e ӪUU n^uses these file type recognizers to generate an zinventoryn describing the files in the ߪUU nsoRusers data directory. An inventory has a header and a body. The header lists the 몚UU ngnLdata directorys full pathname, the reports creation date, Dracos version y UU nshKnumber, and an optional, user-defined documentation string. The body of an nduUU@ ninDinventory consists of a series of file entries sorted by file type. UU n t\Inventory file entries are generated by file type zreportersn. There are two types of 'UU n fZreporters: zfsortedn reporters sort the entries they generate by file name whereas 3UU zfiQcsortedn reporters sort their entries by entry content. Draco currently only s?UU no Jsupports Common Lisp function reporters, partly because the Unix command KUU nleUline length limit makes it inconvenient to implement zcsortedn reporter Unix sWUU n rRcommands. If no reporter is specified, Draco uses a default reporter which simply cUUH natGuses the file type recognizers output as the files report entry.  몚{UU ndaWMany data files are simply lists of KV pairs so we have provided a zKV-reportern UU nanSfacility. A KV-reporter generates report entries containing a subset of the files DinUU nf KKV pairs. The user specifies a list of desired keywords. Any KV pair whose ry UU nenOkeyword is an element of this list will be part of the files inventory entry. n fUU nsWF-sorted reporters, e.g. the default reporter, will list these pairs in the order they zfiUU norQoccur in the file whereas c-sorted reporters will sort the pairs using the order êUUH nLi)defined by the desired keyword list.  n۪UU nMThe KV-reporters lexical analyzer may either be a Common Lisp function or a 窈UU n sLUnix command, and it must take one argument, a file name. It must return a ulUU nimLstream of keyword and value tokens. Each token is an ASCII string, possibly rUU@ n6containing blanks, terminated by a newline character. d[o\\UU HH\[ oHHZ^ 0inUU nf OThe following directives define a file type for OIF calibration files and a KV-UU@ nkereporter for such files: #` of(define-file-type .` :nameOIF-calib 9`  t%:documentationOIF (calibration) iD` ey:super-typeOIF O`  f:recognizer(make-pathname wZ` p u:defaults*tools-dir* e` pby:nameOIF-calib p` pUU:typesh) ep{` al :reporter(define-KV-reporter un` :nameOIF-calib-reporter d` ar:lex-fn(make-pathname ret` UU:defaults*tools-dir* `  t:namephead ` UU:typee) ,` ew:reporter-type ` :c-sorted) ` UU:reporter-type:c-sorted) 모UU nMIn this example, the KV reporters lexical analyzer is a Unix command (more UU na Iprecisely, a Fortran program). An equivalent example using a Common Lisp tUU@ n Hlexical analyzer may be found in Draco:Samples;file-types.lispn. caUU` On DThe syntax for specifying the desired keywords is illustrated here: pe,` (define-report-keywords 7` :reporterOIF-reporter uB` 0:keywords(IMAGETYP OBSERVAT FILTERS DATE-OBS M` e- UTRADEC) nX` ) pUU :nJdefine-report-keywordsn directives should be placed in the appropriate |UU@ nUUinitialization files. UU`  Packages UU nheUThe user should use Draco:define-packagen to describe the analysis systems he -UU@ nMwishes to use. To describe IRAF, for example, one might enter the following: ` (define-package t` ex :nameIRAF s` mo):documentationIRAF analysis package r` ui:file-typeOIF g` 1:begin-cmd/usr/stsci/irafx/unix/hlib/cl.csh ` Ril/:initialize(cl.logmode = \errors trace\ tax ` Te  cl.logfile = \~log\ d ` U cl.keeplog = yes) ey"` :end-cmdlogout) I:UU nWThe file type must be defined by define-file-typen (see the preceding section). UTFUU AY:begin-cmdn and :end-cmdn specify the command strings for invoking and exiting RUU n bIthe package respectively. IRAF has its own command language interpreter, ^UU@ PaLcl.cshn, and the command for exiting this interpreter is logoutn. tvUU nlyXThe optional :initializen specifies a list of commands to execute as soon as the ghUU ninUpackage is invoked. Draco {command templatesn are strings that may contain the d ]i^^ HH!^] HH\a ,csUU n RSspecial token ~logn Draco creates commands corresponding to these templates .loUU nd Qby translating any instances of this token to the name of the log file that will oUU@ nUUAbe created when the Draco-generated analysis script is executed. 6UU`  Converters FOUU n:bVIt would appear that every scientist has to cope with at least two data file formats. [UU n bLThough FITS (Flexible Image Transport System) is widely used by astronomers gUU nclQas a file transfer format, many data analysis systems do not operate directly on sUU nopPFITS files but on their own native data file format. For example, IRAF can read ghUU@ ninPand write FITS files, but most of its functions use its native data format OIF. tUU nQConceptually, data file formats can be viewed as nodes in a directed graph whose UU nRedges correspond to format conversion programs. zIn the futuren, Draco will UU natQautomatically invoke the appropriate converters thus enabling the user to ignore gUU nthKformat differences whenever possible. For example, suppose we have data in tedǪUU nneNFITS format and wish to modify it with an IRAF function. Draco would generate ӪUU nouNa script that converts the data into OIF, invokes the IRAF function, and then ߪUU@ n b*converts the resulting data back to FITS. UU`  b Data Types UU (nclPA data type can be viewed as an abstract file type. Later releases of Draco may UU (nopLsupport other data type implementations, e.g. ASCII stream output or status ea(UU@ (n 5codes. Until then, we define a data type as follows: s9` +fo(define-data-type D` ,ep:nameimage O` .ie-:documentationscience image pixel array Z` -s :file-types(OIF-object)) n rUU` /nhecA data types :file-typesn must be defined by define-file-typen (see section 6.1.2). ablUU` 'no Primitives UUUU 0nifRPrimitives represent abstract analysis tasks. For example, we might represent the UU@ 0nan)task of removing bias counts as follows: D` 1e (define-primitive ` 2nv:nameremove-bias , ` 3un&:documentationremove bias signal ` ?ng.:reconciled-input((data-set :disjunctive)) ` @UU:outputdata-set ca` 4ab':implementations(NOAO-remove-bias)) maUU 5n (MHere we are subtracting the bias signal from the object images and remaining uUU 5n (Ucalibration data in an entire data set. The data types referenced by :reconciled-n'UU 5cinputn and :outputn must be defined by define-data-typen (see preceding section). 3UU 5leY:reconciled-inputn specifies the data types that the primitive reads. Each input data i?UU 5nfiZtype may be annotated by a zreconcile typen using the syntax illustrated above. The KUU 5nseMreconcile type determines what happens when multiple inputs are present. The 0WUU 5nvibdefault value niln indicates that an error should be signaled whereas :conjunctiven cUU 5nPindicates that the primitive should treat all of the data as a single input and iloUU 5etZ:disjunctiven causes the primitive to process each input separately, i.e. iterate over {UU 5nov[its inputs. Each :disjunctiven data type must be associated with the same number of gesd"_raae taHZd#`bA oHZd UU` ne  iHH$a_ iHH^g 'leUU 5nieRinputs. These inputs are processed in parallel, i.e. the command is first invoked UU@ 5nd Non the first set of :disjunctiven inputs, then on the second set, etc. *UU }e \:outputn specifies the data types that the primitive writes and :implementationsn ul6UU }n Rspecifies the implementations that actually perform the abstract task. These must BUU@ }ns Ibe defined by define-implementationn (see the following section). ZUU n:d_In this case, remove-biasns input is one or more data sets represented by the pdata-UUfUU pts^setn data type. Each implementation of remove-biasn must create a data set for each rUU@ n$input data set or modify its input. taUU n\If a data type is associated with the default reconcile type (niln), the parentheses iUU nRsurrounding it may be omitted. And if there is only one input data type and it is UU nThXassociated with the default reconcile type, :reconciled-inputn may be the symbol d UU n oOnaming the input data type. The following primitive illustrates this shorthand \:oUU@ ns syntax: yp` iv(define-primitive ` ~:namefind-like-images f` tiE:documentationidentify images that may be meaningfully combined }` y :reconciled-inputdirectory ` Vec:outputimage-set ` , %:implementations(find-exposures)) oUU nseQThis is also an example of a primitive that can produce several instances of its n&UU ns\output data type for each instance of its input data type. find-like-imagesn reads a ta2UU nXdata directory and creates an pimage-setn for each set of images in the directory se>UU n Lthat can be meaningfully combined. The newly created image sets can then be anJUU@ nUU#processed by some other primitive. rebUU` :r Procedures ut{UU( %nboOA procedure  is an abstract user program. More precisely, a procedure is an ustUU %nndUabstract user zpipelinen because Draco currently does not support iteration or UU %n Pbranching (see section 7). A procedure for extracting (one-dimensional) spectra e UU@ %nnemight be defined as follows: o` &ct(define-procedure ` )ag:nameextract-spectra , ` *sK:documentationremove bias/dark signals, flatten, then extract spectra ive` 6se<:primitives(remove-biasremove-darkflattenextract)) f骓UU 7nf FDraco creates a Common Lisp package for each procedure, and defines a UU 7nryefunction startn in this package, in this case extract-spectra:startn. The user invokes cUU@ 7n cEa procedure by calling its startn function (see section 6.2). UUU` ze Implementations re2UU !n:rIAn implementations name must be the name of a Common Lisp function that r>UU !nelOis used to implement its associated primitive. Since these functions are often useH.%1'%b`eA H.%1' onh wor Running H/F 2  d&c ii od'dggexacHکV-(ebA tHکV- n h ve> # p of  17 p Running H/F 1  HH)fhB rHH ceUU` na  HH*gd HHax -:sUU !n iHimplemented by invoking analysis system procedures, Draco allows one to ctUU@ !n.2Bassociate an implementation with an analysis system, for example: #` na(define-implementation Com.` 8th:nameNOAO-remove-bias s9` 9 i>:documentationremove bias signal from a directorys data D` :%:packageIRAF O` /:initialize-once(noaoimredccdred)  Z` P :inputdirectory &e`  :outputdirectory) o}UU AncIf a :packagen (optional) nis specified, it must be a package defined via define-HUU AMpackagen (see section 6.1.3). One may also specify initialization command UU AnH/Xtemplates (ibid.). :initialize-oncen, a list of strings, lists the commands that UU AnUUFmust be invoked before the implementation can be used. These commands UU AnSwill be executed in the order given. In this case, NOAO-remove-biasn should DrUU@ Anctdnot be invoked unless the noaon, imredn, and ccdredn modules have been loaded. ѪUU nemZThere is also an optional :initializen specification that enables the user to list ݪUU@ ns Lcommands that must be invoked before each invocation of the implementation. UU >nJThe named Common Lisp functions first argument must be a stream, and its UU >nQremaining arguments must be lists of file pathnames. These lists must correspond t UU >nsp[with the implementations :inputn file-types and be in the same order. The function e sUU >n mOshould print the appropriate shell script commands to its stream argument, and %UU@ >nn>return a list of pathnames that these commands will generate. CUU` ke0Invoking Procedures: The start Function ma[UU  AVstartn expects a single argument, a list of input file pathnames. When invoked, it gUU n ASfirst updates Dracos internal model of the users data directory by examining the es sUU n [directorys actual contents. The file Draco.invn, in the data directory, is updated s tUU@ n accordingly. UU =st`startn then determines its arguments zsignaturen, i.e. the set of file-types that are LUU =nstRrepresented in the input file list. This signature determines how the procedures UU =nthYconstituent primitives will be translated into implementations. If startn finds a pUU =nanOtranslation, it will then attempt to generate and invoke an executable (Bourne proǪUU@ =nt 3shell) script for the procedures first primitive. @ >ߪUU Bnt RNote that Draco cannot determine ahead of time if a translation will succeed. The 몐UU BnrtRusers data might cause an implementation to generate too little or too much data UU BnmeJto be reconciled with a succeeding primitives input requirements. Such a UU@ BnatRdiscrepancy can only be discovered by actually attempting to use the translation. UU ;ninNGiven a translation, the file-types required by the resulting implementations 'UU ;nstQinduce a second signature which may be a proper superset of the input signature. t3UU ;nRAs a result, we must handle the case where an implementation requires a file-type ?UU ;nSthat is not part of the input signature. Our solution is to model the execution of KUU ;n pUthe executable script we generate with a simple data structure called the zad hoc tWUU ;zYfile listn. The files in this list were either specified as input or generated by the cUU ;ncaUprocedure earlier. If an implementation requires files of a type found in the ad hoc soUU ;nusSfile lists signature, Draco searches the ad hoc file list for them. Otherwise, it be {UU@ ;nsu$searches the users data directory. s.H1'+hfkB aH1'  uh p. 8p What Is Draco? p 27 December 1993  reHH,ic HHz ic` qsu References in)UU nsGilliland, Ronald L. 1992. Details of Noise Sources and Reduction Processes, to appear in {Basic Astronomical n5UU@ { oeCCD Observing and Reductionn, ed. S. Howell (San Francisco: Astronomical Society of the Pacific). eMUU cne xGraham, Randall 1992. Collage: Foundational Metapplication in zaccessn, Oct-Dec 1992, available via Gopher from r YUU@ cn opubs@ncsa.uiuc.edu. qUU nproJohnston, Mark 1987. An Expert System Approach to Astronomical Data Analysis, zProceedings of the Goddard st}UU@ z sGConference on Space Applications of Artificial Intelligencen, NASA. nsuUU nrnLucks, Michael and Gladwell, Ian 1992. Functional Knowledge Representation in AI Applications for Scientific UU@ n. qComputing in zAAAI 1992 Fall Symposium on Intelligent Scientific Computationn, ed. E. Kant and R. Keller. UU` {nXMandel, Eric 1993. The ASSIST Graphical User Interface in zAXAF Newsn, issue 1. d ѪUU nofrMiller, Glenn E.; Johnston, Mark D.; and Hanisch, Robert J. 1989. Proposal to the National Aeronautics and Space ݪUU n elAdministration Applied Information Systems Research (NRA 89-OSSA-21), Space Telescope Science Institute, . 骟UU@ non Baltimore. tioUU` nnlReid, Ian 1990. Interfaces to Numerical Packages in zComputer Physics Communicationsn, vol. 61.z JoUU` bn 9Steele, Guy L. 1990. {Common Lispn, Digital Press. d-jUn acH K.khB nH K elh p 1B Draco Design Document  2 p of  17  d/l mDpoumZu0mnl Zu ` 3. hl2q1nmol l2q Mi` mhn nu-2onqlou-onaAeu--d3pAxxte RH 4qorlSH  . H  H5rqsl HacetoHQ = K6srl Q = K leUUh C 27 December 1993  sd7tuHn H@3N `@8uvt H@3N `@HHFootnoteH9vu{tDww Footnote :wv D  HH;xp HHgz *UU n3.SAfter generating and executing a script for the procedures first primitive, Draco UU n]updates its internal model of the data directory and the directorys Draco.invn file. UU@ n8The remaining primitives are processed in the same way. B` q Conclusions SdUU n. sThe prototype we have described is a plausible one, but the results we obtained using it and its predecessors were KpUU nrdefinitely mixed. We are able to reduce data and are convinced that given enough resources the prototype could be |UU nudeveloped into a useful system, but we have doubts about the desirability of this approach. In the remainder of this UU nssection we describe a few of the problems we encountered. Some of these problems could be attributed to our use of UU@ nDuIRAF while others clearly have more to do with data analysis than with Draco, but they are all relevant nonetheless. UUU` #neClash of Intuitions sʪUU <nedbThe only good interface is an intuitive interface, but these are not easy to find for a number of ֪UU <nry_reasons. Computer users often argue about the relative merits of various system interfaces and ame⪟UU <newhen one considers that a large system interface is often the product of many minds, it is no wonder hUU@ <nne?that the end result is rarely deemed intuitive by its users. iniUU Dn aaSoftware has no intuition of course, but good machine interfaces and good interactive interfaces UUU Dnd hmust share at least one attribute and that is consistency. IRAFs interactive interface is plagued with UU Dnathe usual inconsistencies. A procedures arguments are either required or optional. Its required t*UU Dn^arguments are usually specified in an order-dependent manner, but it may also require certain 6UU Dnll`keyword arguments which may be given in any order (after the syntactically required arguments). gBUU Dnn ]Some arguments may override others, and all optional arguments have default values which may nNUU Dnofnchange from version to version. This zmayn be intuitive to a human user, but encoding this intuition in ZUU@ Dnem*a computer program is a painstaking task. rUU En haThe task is not an impossible one of course. For example, if Draco wishes to use its own default U~UU En h\argument values, it may do so by explicitly specifying all argument values when invoking an UU En s`analysis system procedure. However, such verbosity often results in commands longer than IRAFs UU EnWcommand buffer and one must then devise ways of compactly expressing lengthy commands. reUU EnUUfMeanwhile, if a machine interface existed, it would enable one to use a single technique, e.g. a list UU@ Enll{v|t H<SU `@HH 1Heading RuleiH2 ?|{~ti}} d Chapter Rule s@}|n) othHVJ@ `@A~|t sHVJ@ `@H(oH(o Chapter RuleieHHBj HHi 6p.UU` n 5Sample Draco Script (abridged, long lines truncated) l` ri #!/bin/sh &` # script title: REMOVE-BIAS f1` er# remove bias signal <` |en'# creation date: 07-Nov-1993, 20:16:09 uirG`  v# Draco version: 1 ofR` ^ F ]` _he!# create and initialize log file wh` t 8LOG_FILE=/tmp_mnt/marian/data4/rsg/DracoQIJa13486.log ces`  echo > $LOG_FILE ~` UU ` UU# initialize package IRAFp ` L9PACKAGE_INPUT=/tmp_mnt/marian/data4/rsg/DracoRIJa13486 ` Z?5echo cl.logmode = \errors trace\ >> $PACKAGE_INPUT u` 2echo cl.logfile = \$LOG_FILE\ >> $PACKAGE_INPUT ` ,echo cl.keeplog = yes >> $PACKAGE_INPUTp V` p o` pie-# initialize implementation NOAO-REMOVE-BIAS ` pecho noao >> $PACKAGE_INPUT ` Xpleecho imred >> $PACKAGE_INPUT i` Ypecho ccdred >> $PACKAGE_INPUT ` p#  i` pIA)# invoke implementation NOAO-REMOVE-BIAS n ` p | n` ]p 0G# no files of type OIF-BIAS for /tmp_mnt/marian/data4/rsg/oif0467.imh. #` [po .` peaG# no files of type OIF-BIAS for /tmp_mnt/marian/data4/rsg/oif0602.imh. an/9` pa1 6D` qp!# create averaged OIF-BIAS files O` p [echo /tmp_mnt/marian/data4/rsg/oif0516.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst _mnZ` dp/D[echo /tmp_mnt/marian/data4/rsg/oif0515.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst e` epec[echo /tmp_mnt/marian/data4/rsg/oif0514.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst > $p` fpV[echo /tmp_mnt/marian/data4/rsg/oif0513.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst {` gpec[echo /tmp_mnt/marian/data4/rsg/oif0512.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst ` Y` hp>>[echo /tmp_mnt/marian/data4/rsg/oif0511.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst MOV` ip[echo /tmp_mnt/marian/data4/rsg/oif0510.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst if0` jp[echo /tmp_mnt/marian/data4/rsg/oif0509.imh >> /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst sg/` phecho zerocombine @/tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst output=\/tmp_mnt/marian/data4/rsg/D p_` psg f` mpnt# remove OIF-BIAS signature 86` kpeecho ccdproc /tmp_mnt/marian/data4/rsg/oif0574.imh zero=\/tmp_mnt/marian/data4/rsg/DracoSJJa13486.i ` npeceecho ccdproc /tmp_mnt/marian/data4/rsg/oif0573.imh zero=\/tmp_mnt/marian/data4/rsg/DracoSJJa13486.i ` op /eecho ccdproc /tmp_mnt/marian/data4/rsg/oif0572.imh zero=\/tmp_mnt/marian/data4/rsg/DracoSJJa13486.i g` lpt/ i` pp12#invoke package IRAF /` pa1echo logout >> $PACKAGE_INPUT  ` pri?/usr/stsci/irafx/unix/hlib/cl.csh < $PACKAGE_INPUT > /dev/null 486` p# rm $PACKAGE_INPUT t/ ` pif 0+` parecho created files: a16` p8echo  /tmp_mnt/marian/data4/rsg/DRacoQIJa13486.sh > A` ptaecho  $LOG_FILE L` p 9echo  /tmp_mnt/marian/data4/rsg/DracoSJJa13486.lst 1W` \p/t9echo  /tmp_mnt/marian/data4/rsg/DracoSJJa13486.imh H CM rH N t/` xifHSmall parts of the system are implemented via Unix utilities and/or C. ndDgmpntHHE HHUU a4` er(Appendix  Implementation Notes 864UU`  lMetaobject Protocol Usage LUU nIR^We use Common Lisps Metaobject Protocol (MOP) in order to facilitate entity definition. User-XUU n$Pddefined entities are defined in terms of each other. Unfortunately, we cannot always insure that an dUU n cdentity is defined before it is referenced. (And even if we could, imposing such a restriction would pUU n `not win us any friends.) Our solution to this problem is to create entities as soon as they are |UU necXreferenced and initialize them when the user defines them. The MOP enables us to locate UU ncpreviously created entities by associating an entity list with each entity type. The end result is ia UU@ nd/Kthat memory is conserved and entity specification errors are easily found. ntUU` "Command Template Processing ʪUU un`Intuitively, we have an entity definition phase that is followed by an entity usage phase. This ֪UU unrowsecond phase is signaled by a call to the entitys pvalidaten method. pvalidaten ensures that its argument . U⪟UU@ un Zis well-formed. This may entail validating other entities, maybe even all other entities. UU vn^Validation has the side effect of initiating command template processing. Recall that command UU vnulxtemplates are strings that may contain Draco tilde directives, e.g. p~logn or p~in n. We will substitute UU vnecjactual file names for these directives, but this substitution process has two phases. In the first phase, UU vnremcommand templates are expanded into vectors of {commandn {elementsn. A command element is either h*UU vnrva string, a {data-filesn structure, or the symbol p:logn. A data-files structure represents a p~inn or p~outn 6UU vnenmdirective whereas p:logn represents a p~logn directive. The remainder of the command template is iBUU vno `represented by the appropriate substrings. This vector of command elements, generated as a side uNUU@ vned`effect of validation, is a more useful data-independent representation of the command template. VafUU ynidcThe second phase of this substitution occurs when it is time to generate script commands, the data-es rUU ynay`files structures in the command element vectors are populated with information about the users ~UU ynalfactual data. Information about the reconcile types associated with the relevant data types is used to UU yncoddetermine whether the script command can be generated, and if it can, what it should be. If we have thUU yn vgthe right amount of input, the appropriate string values are substituted for the data-files structures entUU@ yn cand p:logn, and the resulting vector of strings is concatenated to produce a script command. ThH,F~tes TableFootnotep;G ;ed  a;;H<R `@HHt rH<R `@HH TableFootnotemdIestutH~6J H~6 fiUU` nth"<$paranum><$paratext><$pagenum> ` mon"<$paranum><$paratext><$pagenum> )US UT`  I"<$paranum><$paratext><$pagenum> HnU(O `@K HnU(O `@HwHwTable of Contents Specificationn bHR-L bHR- t UU` nhe"<$paranum><$paratext><$pagenum> HO `@M HO `@HHList of Figures SpecificationiHR6N mHR6 UU` n"<$paranum><$paratext><$pagenum> HOS `@O HOS `@HHList of Tables SpecificationdPaH~Q H~ ` x1, 23 ` x$<$symbols><$numerics><$alphabetics> $p` x> Level3IX &` xm> Level2IX >0` xUT Level1IX IC` watLSymbols[\ ];Numerics[0];A;B;C;D;E;F;G;H;I;J;K;L;M;N;O;P;Q;R;S;T;U;V;W;X;Y;Z L` xTa <$pagenum> ts Hl@mV `@R Hl@mV `@HuHuIndex SpecificationdStEOl2qT l2q  if mTThis report contains a description of the motives driving the Draco project, a high- mraSlevel description of the system, and a detailed specification of its I/O behavior. `@$@ mMThe intended audience includes potential Draco users and software engineers. > m^Our goal is to create a usefulm system that will help astronomers concentrate on their L mPresearch by reducing the number of mundane data reduction tasks that have to be Z m Hperformed manually and by reducing the amount of arcane knowledge about h@ m\ Gastronomical data analysis packages needed to reduce and analyze data.  mge[Our system attempts to serve as an interface to any existingm data analysis system. ex  mJBecause these systems invariably have command line interfaces, this means @ m=generating suitable commands and subsequently invoking them. fZuU aZu pr` 1992-07 HV_ aHa `@ $xpProcedures are implemented as primitives and are sometimes known as procedural primitives as a result. We may to@ $xuladd a :primitivesx keyword to define-primitivex and do away with define-procedurex in some future version of Draco. dWndy HHX uHH  al` edAppendix  Acronyms .UU ngeAIArtificial Intelligence e a:UU nan#CLIMCommon Lisp Interface Manager em.FUU n %FITSFlexible Image Transport System hRUU nnt+IRAFImage Reduction and Analysis Facility era^UU nanKVKeyword-Value jUU n)MOP(Common Lisps) Meta-Object Protocol vUU n.NOAONational Optical Astronomy Observatories UU nOIFOld IRAF Format UU nSNRSignal-to-Noise Ratio UU@ n4STSDASSpace Telescope Science Data Analysis System adYstodZ pritHH[ rHH UU` n H1'\ H1' h p&Figure 1p 27 December 1993  Q$]l UQ$ ` C oQ^l Q  ` yIR IJd _slJd S@0/`lOS@0/Z"s$GalZ"s$Gptil ZFbp"sS@"s$GblFS@"s$GUU ZFS@"sQ* oclSQ* Q* obp"s_ dlbp"s_ c0Lbp"sQ"s_ elQ"s_ pritS@"sQ0LR13SoflQ*R13Soid ' G gld ' G Hd 5jg' K)^G $hlK)^G $2DeR15K)^H"i% &ilUH"i% &kl"m "m IgHIgH"iJ "iKY>oN0%jlJ<>o =_KY>oN0%H% ;klH% ;um` ɹll um` ɹu#/u#/$SPACE TELESCOPE SCIENCE INSTITUTEEml E  ` uG UH Kn cH K h psC Draco Design Document  15 p of  17  bpdoprit~Z pl ~Z  o` GAPSB Technical Report HqCl H  ` u2 Revision Q$r Q$  ` Draco Design Document Qs Q  ` y Felix Yen % EtE E SP ` uIEE HHu HH UU` n H1'v H1' h p2Implementation Notesp 27 December 1993  H Kw H K h p;Draco Design Document 16 p of  17  HHx PHH UU` n H1'y H1' h p&Acronymsp 27 December 1993  H Kz iH K h p;Draco Design Document 17 p of  17  i dAtLeftdBRightdlSPFirstdt ReferenceudTOCdIXd FirstdFdKdMdPemdSDedVdYd[d] d_ sidd dp dy dcdjFiguredNotesd AcronymsdFiguredAcNotesd Acronyms i G f n@ )1Body 1Body . f S ) Step Step Numberu S:.\t. f qHQ ) $K1Heading 1Heading RuleH:.\t1BodyP. $$$ f @ )2Body2Body. $$$f n )ccljExtractExtracto. f )Abstract. f )CBullet. fSE ) 1Step Step Numbert S:.\tStep. HHH f@ )H3Body3BodyH. ngZ f@ ) AuthorPurpose. fy ) Rev Prefix. f )Number. f )CellBody. f@ )1Body1Body. fE ).EquationEquation Number E:(EQ ). ZZ6f )gclfExtractExtract. fFA ) Figure Table Top Step NumberF:FIGURE .\tBody. f )Body. f )  CellHeading. .f@ ) Purpose FirstBodyd. . f ).CStepi. onf ) TableFootnote. fT )f TableTitle Table Top Step NumberT:TABLE .\t). f!n@ )fH1Body1Body. ZZ6f"p )clExtractExtract. f#T )Pu s TableTitle Table Top Step NumberT:TABLE .\t. f$ ) footer first. f%y )Revision. f&y )aAuthorst. f'$< )Title. f)w )  footer left. $$f*p )fclExtractExtract. $$$f+ )Footnote Quote. 6$$f, )6Footnote Bullet Bullet Symbol\t. f-n )  3HeadingTOCh. f.m )Ti   2HeadingTOC. cf/ )r~  1HeadingTOC. cf0n ) FigureLOF. cf1n ) TableTitleLOTQ. f2x ) SeparatorsIX. f3x ) SortOrderIX. $f4x )mLevel3IX.  f5x )fLevel2IX. f6x ) Level1IX. f7w )  GroupTitlesIX. f8x )aIndexIX. f9 ) Num Prefix. . HH f:HQ ) lOr3HeadingH:..\t3Body. HHH f;n@ ) H3Body3Body. HH f<HQ ) lf3HeadingH:..\t3Body. f=x )Footnote. f> )Footnote. f?@ ) FirstBodyBody. f@w ) header. fAp )nheader. fBp ) footer right. fC < ) Title. lfD@ < ) Title Chapter RuleAuthor. lfG@ < ) Title Chapter RuleAuthor. H fHFQ )6Figure Table Top@ Step NumberF:FIGURE .\tExtract. ZHHfI )ZBullet Bullet Symbol\t. $$$ fKn@ )2Body2Body. fMn@ )6<1Body1Body. $$fOHQ ) H2Heading H:.\t2Bodye. $$fPHQ ) H2Heading H:.\t2Bodyr. fR )  CellHeadingi. fS )CellBody. fTHQ ) $1Heading 1Heading RuleH:.\t1Body. fUm )Abstract. fXm )Keywords. fZm ) Key Prefix. mo) zVm ) zVn )Byr egYp ) q )  ;cor )  Bullet SymbolegYs )Callout= t )EmphasiszVu )ga24vEquationVariables w ) ea zVx )ByzVy ) hz )Emphasis h{ ) | ) Equation Number } ) Run-In Heading ~ ) f Step Number=  ) Subscript=  ) Superscript  )  Step Number  )   )  p ) zV ) zV )aou 3egY )regular lisp/unix egY )aregular lisp/unixegY )nsegY )ge24 h )Emphasis zV ) zV )egY )small lisp/unix  )  egY )uIn3egY )small lisp/unixmbe < ) zV )$<zV )F){ ) h )  ) )  )Z )@ )@ )a )Y  )Za  )Z  )Za5E:5 )Thin6 )Medium7 )Double8 )Thick@9 ) Very Thin ) 9 )# ) ) )6RSR6RSRY6RSR6RSRpFormat A9# ) ) )6RSR6RSR6RSR 6RSRFormat B a q a   +Comment k U Vn V q W t X w Y z Z } [  \  ]  ^  `  ) a  b @ c  ) e  g  h Y j  ) l  m  ) 9 1d  )BlackT! *YWhite)ddA + )Reddd ,Green@dd  - TBlued .Cyand /Magentad 0Yellow Times-RomanSHelvetica-Bold Times-Bold Helvetica Courier-Bold Times-ItalicHelvetica-BoldObliqueSymbolCourierTimesS HelveticaRSymbol Regular Regularo BoldRegularObliqueItalicty)x>& [=7-uכ s?] h!İ t'zlOP.6G̙*IRbɖmw 1T(B~iPM$hnpqŨxOӜrĄpMei^9vQLnB7BV^gs9SdX.m*n`Thhl\L%|EH$kvbl怒eF-20B{0*oJ1 r͝KݍD)R Vo.'|Jo#C1QSD( Zvhl~L,(= nSrܗ?5IqoQ,:>'@P]y-/FܖPTGe *