source: branches/alma/admin/requirements2.tex@ 1881

Last change on this file since 1881 was 728, checked in by mar637, 19 years ago

fixed 'IFs with different number of spectral channels' to be priority 1.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
File size: 54.3 KB
Line 
1\documentclass[11pt]{article}
2\usepackage{a4}
3\usepackage{calc}
4\usepackage{ifthen}
5\usepackage{smartref}
6\usepackage{longtable}
7
8\def\complete{no}
9
10% Adjust the page size
11\addtolength{\oddsidemargin}{-0.4in}
12\addtolength{\evensidemargin}{+0.4in}
13\addtolength{\textwidth}{+0.8in}
14
15\setlength{\parindent}{0mm}
16\setlength{\parskip}{1ex}
17
18
19\title{ASAP - ATNF Spectral Analysis Package\\
20 Software Requirements - Development Cycle 2 }
21 \author{Chris Phillips \& Malte Marquarding}
22
23\newcounter{requirement}
24\newcounter{subrequirement}
25
26\addtoreflist{requirement}
27\newcommand{\reqref}[1]{R\ref{#1}-\requirementref{#1}}
28
29\newcommand{\makenote}[1]{{\bf \tt \em#1}}
30
31\newcommand{\anitem}[2]{\smallskip \parbox[t]{2cm}{#1}%
32 \parbox[t]{\textwidth-2cm}{#2}}
33
34\newcommand{\showreqcounter}{
35 R\arabic{section}.\arabic{subsection}-\arabic{requirement}
36}
37
38\newcommand{\showsubreqcounter}{
39 R\arabic{section}.\arabic{subsection}-\arabic{requirement}.\arabic{subrequirement}
40}
41
42\newcommand{\status}[2]{
43 \ifthenelse{\equal{#1}{Started}}{Started \hspace*{1cm} {\em Priority #2}}
44 {\ifthenelse{\equal{#1}{Not started}}{Not Started\hspace*{1cm} {\em Priority #2}}
45 {\ifthenelse{\equal{#1}{Done1}}{Completed}
46 { \ifthenelse{\equal{#1}{Duplicate}}{Duplicate?}
47 {#1}
48 }}}
49}
50
51% Also Deferred, Obsolete
52
53% Requirement command
54% Summary
55% Status
56% Priority
57% Time estimate
58% Percent complete
59% Completion date
60% Text
61
62%\newarray\Requirements
63
64%\newcounter{numreq}
65
66\newcommand{\requirement}[7]{
67 \setcounter{subrequirement}{0}
68 \stepcounter{requirement}
69
70 \ifthenelse{\equal{\complete}{yes}}
71 {\dorequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}}
72 {\ifthenelse{\equal{#2}{Done1}
73 \or \equal{#2}{Deferred}
74 \or \equal{#2}{Removed}
75 \or \equal{#2}{Obsolete}}{}
76 {\dorequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}}}
77}
78
79\newcommand{\dorequirement}[7]{
80 \hspace*{2mm}\begin{minipage}{\textwidth-2mm}
81 \setlength{\parindent}{-2mm}
82 {\bf \showreqcounter\ \bf #1} \\
83 #7 \\
84 \hspace*{1cm} \status{#2}{#3}
85 \end{minipage}
86
87 \typeout{REQUIREMENT: \showreqcounter & #1 & #2 & #3 & #4 & #5 & #6 :ENDREQ}
88}
89
90\newcommand{\subrequirement}[7]{
91 \stepcounter{subrequirement}
92
93 \ifthenelse{\equal{\complete}{yes}}
94 {\dosubrequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}}
95 {\ifthenelse{\equal{#2}{Done1}
96 \or \equal{#2}{Deferred}
97 \or \equal{#2}{Obsolete}
98 \or \equal{#2}{Removed}}{}
99 {\dosubrequirement{#1}{#2}{#3}{#4}{#5}{#6}{#7}}}
100}
101
102\newcommand{\dosubrequirement}[7]{
103 \hspace*{2mm}\begin{minipage}{\textwidth-2mm}
104 \setlength{\parindent}{-2mm}
105 {\bf \showsubreqcounter\ \bf #1} \\
106 #7 \\
107 \hspace*{1cm} \status{#2}{#3}
108 \end{minipage}
109
110 \typeout{REQUIREMENT: \showsubreqcounter & #1 & #2 & #3 & #4 & #5 & #6 :ENDREQ}
111}
112
113
114\newcommand{\extendedrequirement}[7]{
115 \setcounter{subrequirement}{0}
116
117 \hspace*{2mm}\begin{minipage}{\textwidth-2mm}
118 \setlength{\parindent}{-2mm}
119 \stepcounter{requirement}
120 {\bf \showreqcounter\ #1}
121 #7
122 \hspace*{1cm} \status{#2}{#3}
123 \end{minipage}
124
125 \typeout{REQUIREMENT: \showreqcounter & #1 & #2 & #3 & #4 & #5 & #6 :ENDREQ}
126}
127
128
129\newcommand{\reqeqn}[1]{\\\hspace*{1cm} $#1$}
130
131\let\oldsection\section
132\renewcommand{\section}[1]{\setcounter{requirement}{0}\oldsection{#1}}
133
134\let\oldsubsection\subsection
135\renewcommand{\subsection}[1]{\setcounter{requirement}{0}\oldsubsection{#1}}
136
137\begin{document}
138
139\maketitle
140
141
142%\tableofcontents
143%\newpage
144
145\section{Introduction}
146
147ASAP has been written to replace the venerable single-dish software
148{\tt spc} for processing of single dish spectral line data from all
149ATNF observatories. Version 1.0 of ASAP was released in March
1502005. This document reflects an update of the initial requirements
151document. Some new requirements have been added and the requirement
152priorities have been reassessed for the next development cycle.
153
154\section{Scope}
155
156ASAP should be able to process all spectral line single-dish
157observations from ATNF telescopes (Parkes, Mopra \& Tidbinbilla). This
158includes reading the data produced by the telescope, calibration and
159reduction of the data and basic analysis of the data such as fitting
160line profiles etc.
161
162It has been assumed that the following processing is out of the scope
163of ASAP.
164\begin{itemize}
165\item Raster or ``on-the-fly'' mapping (This is handled by
166``livedata'' and gridzilla).
167\item Very complex or specific data processing. (A route into
168 Class\footnote{Part of the GLIDAS software package, produced by
169 Institut de Radio Astronomie Millime\'trique http://www.iram.fr}
170 should be available for advanced processing).
171%%TODO%% give example
172\item Continuum data.
173\item Pulsar timing observations.
174\end{itemize}
175
176\section{Priorities}
177
178Requirements have been given a value of 1 to 3. The other requirements
179will be implemented mainly depending on priority, with ``1'' the
180highest. Priority 3 and some priority 2 requirements will probably not
181get implemented in the duration of the second development cycle.
182
183\section{User Interface}
184
185The user interface (UI) is the most important part of a single dish
186processing package, but probably the most difficult to get right. Long
187term the UI for this software will consist of three parts.
188\begin{itemize}
189 \item A graphical user interface (GUI).
190 \item An interactive command line interface (CLI).
191 \item A scriptable interface for batch processing.
192\end{itemize}
193
194The CLI and scriptable interface are essentially be the same.
195
196The software does not {\em need} to be able to run solely from a
197``vt100'' style terminal. It can be assumed that the user is running
198the software from within a windowed (i.e. X11) environment. This will
199mean it will not necessarily be possible to run the software remotely
200over a slow network connection (e.g. internationally or from home).
201Where possible, operations on the data should be possible from all
202three aspects of the user interface.
203
204The user interface needs to be implemented so that the user can easily
205and transparently work on spectra either one at a time or by
206processing multiple spectra in parallel. This means there must be an
207easy way to select specific or multiple spectra to display or process.
208
209At this stage the development of a GUI has been deferred until the
210basic package has stabilised and most features have been
211implemented. At that stage a decision will be made on how to best
212implement a GUI. On a shorter timescale specific purpose GUIs (such as
213a simple Wizard for processing standard Mopra data) may be produced on
214an as-needed basic.
215
216\subsection{Graphical User Interface}
217
218At this stage a general ASAP GUI has been deferred to a later date.
219
220\smallskip
221
222\requirement{Simple interface}{Deferred}{}{}{}{}{It should be simple,
223intuitive and uncluttered. Specifically, use of many windows
224simultaneously should be discouraged, as should hiding functionality
225behind layers of dialog boxes.}
226
227\requirement{Integrated plotter}{Deferred}{}{}{}{}{The plotting window
228should be a major component of the GUI control, not a separate
229isolated window.}
230
231\requirement{Minimal controls}{Deferred}{}{}{}{}{The interface should use
232 minimal ``always visible'' controls, with use of pull down menus and
233 maybe a toolbar for frequency used functions. }
234
235\requirement{Keyboard shortcuts}{Deferred}{}{}{}{}{Keyboard shortcuts should
236be available.}
237
238\requirement{GUI user preferences}{Deferred}{}{}{}{}{Most user preferences
239(i.e. keywords in the CLI) should be presented in a popup, tabbed,
240dialog box.}
241
242\requirement{GUI line fitting}{Deferred}{}{}{}{}{When performing line
243profile fitting, a spreadsheet type window should be viewable which
244shows the current parameter values (amplitude, velocity etc) for each
245line fitted and allow the user to change these parameters or set the
246current value as fixed. This GUI should stay synchronised with any CLI
247changes to these values.}
248
249\requirement{Mopra online GUI}{Not started}{1}{}{}{}
250{A simple GUI to do very basic online reduction of Mopra data should
251be available. This should include averaging data, quotient }
252
253\subsection{Command Line Interface}
254
255The command line interface is the main user interface to ASAP. It is
256implemented in ipython using a objected oriented command approach.
257
258\requirement{Virtual CLI}{Obsolete}{}{}{}{}{While the GUI should be the main
259interface for new users and for basic manipulation, some tasks can be
260more efficiently performed using a CLI. A virtual CLI could be
261integrated as part of the GUI.}
262
263\requirement{CLI keyword/argument}{Obsolete}{}{}{}{}{The CLI should have a
264keyword/argument form and never prompt the user for specific values
265(the user should be able to change values which are retained until
266they wants to change them again).}
267
268\requirement{CLI case insensitive}{Obsolete}{}{}{}{}{The CLI should be case
269insensitive and accept minimum matching and short forms of
270keywords.}
271
272\requirement{CLI available routines}{Done1}{}{}{}{}{The user must be able to
273quickly and easily see from the command line the available routines
274and keywords which affect it, so they can see which parameters may
275need changing.}
276
277\subsection{Scripting}
278
279\requirement{Scripting}{Done1}{1}{}{}{}{It must be possible to run the
280software in a scripting mode. This would be to process large amounts
281of data in a routine manner and also to automatically reproduce
282specific plots etc (So the scripting must have full control of the
283plotter). Preferably the scripting ``language'' and the CLI would be
284the same.}
285
286\requirement{Standard scripts}{Not started}{1}{}{}{} {ASAP should come
287with sample scripts which users can use for standard observing modes
288(e.g. standard Mopra observing, Parkes polarimetry etc)}
289
290%\requirement{Scripts from History}{Duplicate}{}{}{}{}{It would be worthwhile
291%having a method to auto-generate scripts (for reduction or plotting)
292%from current spectra history, or some similar method.}
293
294\section{Plotter}
295
296The plotter should be fully interactive and be an integral part of the
297GUI and software interface.
298
299\requirement{High quality plots}{Done1}{}{}{}{}{It must be able to
300produce plots of publishable quality.}
301
302\subrequirement{Histogram plots}{Not started}{1}{0.5d}{}{} {As well as line
303plots, there needs to be an option to plot spectra in ``Histogram''
304mode}
305
306
307The user must be able to specify:
308
309\subrequirement{Line Thickness}{Started}{1}{0.1d}{}{}{}
310
311\subrequirement{Character size}{Not started}{1}{0.1d}{}{}{}
312
313\subrequirement{Colours}{Started}{1}{0.75d}{}{}{}
314
315\subrequirement{Line styles}{Not started}{1}{0.5d}{}{}{}
316
317\subrequirement{Position of axis ticks}{Done1}{2}{}{}{}{}
318
319\subrequirement{Hard Copies}{Done1}{1}{}{}{}{Producing hard copies
320in postscript and .png format. Other formats may be added on an as
321need basic.}
322
323\subrequirement{Non-interactive hard copies}{Not started}{1}{2d}{}{}
324{It must be possible to produce hard copiers without an interactive
325(i.e X11) plotter starting}.
326
327\subrequirement{Scriptable plotting}{Done1}{1}{}{}{} {All aspects of
328the plotter (zooming etc) must be setable from the command line for
329scripting}
330
331\requirement{Arbitrary plots}{Not started}{3}{}{}{}
332{It must be possible to flexibly select the data to plot (e.g. Tsys vs
333time etc as well as plots such as amplitude vs channel number or
334velocity). Preferably any of the header values for a selection of
335scans could be plotted on a scatter plot (e.g. Tsys vs elevation)}
336
337\requirement{Overlay spectra}{Done1}{}{}{}{}{It must be possible to overlay
338 multiple spectra on a single plot using different colours and/or
339 different line styles. (Including multiple stokes data and multiple
340 IFs).[[CHECK]]}
341
342\requirement{Plot individual spectra}{Done1}{}{}{}{}{It must be possible to
343 plot either the individual integrations (in either a stacked
344 fashion, or using a new subplot per integration)}
345
346\subrequirement{Auto-average integrations for plotting}{Not started}{2}{}{}{}
347{It should be possible to optionally auto-average integrations of a
348scan for plotting (for data thats has not already been scan averaged)}
349
350\requirement{Plotter multi-panelling}{Done1}{1}{}{}{}
351{It must be possible to multi-panel spectra in an n$\times$m size
352grid. It must be possible to easily change the number of plots per
353page, ie define the ``n'' and ``m'' values.}
354
355\subrequirement{Step between plots}{Not started}{2}{}{}{}
356{If more spectra than can fit on the plot matrix are to be plotted,
357then it must be possible to step back and forth between the viewable
358spectra (i.e. ``multi-page'' plots). This includes stepping through a
359single plot on the pages at a time.}
360
361\requirement{Multi-panel: change \# panels}{Not started}{2}{}{}{}
362{When using multi-panelling, the plotter should automatically update
363the plot when the plot matrix dimensions (``n'' and ``m'' are changed)}
364
365\requirement{Plotter interactive zooming}{Done1}{}{}{}{}{It must be possible
366 to interactively zoom the plot (channel range selection and
367 amplitude of the spectra etc.) This includes both GUI control of
368 the zooming as well as command line control of either the zoom
369 factor or directly specifying the zoom bounds. }
370
371\requirement{Zoomed subplot}{Not started}{2}{}{}{}
372{On a single plot, it should be possible to plot the full spectrum and
373a zoomed copy of the data (using a different lie style) to see weak
374features. The user must be able to specify the zoom factor.}
375
376\requirement{Offset plots}{Not started}{2}{}{}{}{Optionally when stacking
377 multiple spectral plots in one subwindow, a (user definable) offset
378 in the ``y'' direction should be added to each subsequent
379 spectra.}
380
381\requirement{Plotter auto-update}{Not started}{3}{}{}{}
382{The plotter should automatically update to reflect user processing,
383either from the CLI or GUI. The user should have to option to turn
384this feature off if they so wish.}
385
386\requirement{Waterfall plot}{Not started}{3}{}{}{}
387{It should be possible to plot individual integrations (possibly from
388multiple scans) in a ``waterfall'' plot. This is an image based
389display, where spectral channel is along the x-axis of the plot, time
390(or integration number) along the y-axis and greyscale or colour
391represent the amplitude of spectra. Interactive zooming and panning of
392this image should be supported. }
393
394\requirement{Waterfall editing}{Not started}{3}{}{}{}
395{When plotting ``waterfall'' plots, it should be possible to
396interactively select regions or points and mark them as invalid
397(i.e. to remove RFI affected data). The plotter should also show the
398time/velocity of the pixel beneath the cursor.}
399
400\requirement{Export waterfall to FITS}{Not started}{3}{}{}{}
401{It should be possible to export the ``waterfall'' plot images as a
402FITs file, for user specific analysis.}
403
404\requirement{Plot line catalog overlays}{Not started}{1}{3d}{}{} {Line markers overlays,
405read from a catalogue should be optionally available. This would
406include the full Lovas catalogue, the JPL line catalogue and radio
407recombination lines. The lines would be Doppler corrected to a
408specified velocity. The user must be able to plot just a sub-section
409of the lines in any specific catalogue (to avoid clutter).}
410
411\subrequirement{Plot user catalog overlays}{Not started}{2}{}{}{}
412{Simple user definable catalogue should be definable for plot overlays}
413
414\requirement{Plot fitted functions}{Done1}{}{}{}{}
415{Optionally plot fitted functions (e.g line profiles or baseline
416fit). If multiple components (e.g. Gaussian) have been fit, it should
417be possible to show the individual functions or the sum of the
418components}
419
420\requirement{Plot residual data}{Started}{1}{0.5d}{}{}
421{It should be possible to plot the residual data with or without
422subtraction of fit functions. This includes plotting the spectra with
423or without baseline removal and the residual after subtracting
424Gaussian fits. The default should be to plot the data with baseline
425subtracted but profile fits not subtracted.}
426
427\requirement{Plot header data}{Not started}{2}{}{}{} {Basic header data
428(source name, molecule, observation time, Tsys, elevation, parallactic
429angle etc) should be optionally shown, either on the plot or next to
430it. This may either consist of a set of values, or only one or two
431values the user specifically wants to see (source name and molecule,
432for example).}
433
434\subrequirement{User define header plot positions}{Not started}{3}{}{}{}
435{The user should be able to define where on the plot the header info
436would appear.}
437
438\requirement{Realtime cursor position}{Done1}{}{}{}{}
439{Optionally, relevant data such as the current mouse position should
440be displayed (maybe with a mode to display an extended cross,
441horizontal or vertical line at the current cursor position).}
442
443\requirement{Plot annotations}{Not started}{2}{}{}{}{The user should be able
444 to define simple annotations. This would include text overlay and
445 probably simple graphics (lines, arrows etc).}
446
447The user must be able to use the plotter window to interactively set
448initial values and ranges used for fitting functions etc. The use of
449keyboard ``shortcuts'' or other similar ``power user'' features should
450be available to save the time of experienced users.
451
452{\em The following requirements are deferred as they require a version
453of Matplotlib not yet available.}
454
455The plotter should be used to set the following values:
456
457\requirement{Interactive channel selection}{Deferred}{1}{}{}{}{Range of
458 spectral channels needed for specific tasks (ie the channel mask)
459 (See requirement \reqref{ref:chansel})}
460
461\requirement{Interactive line fitting}{Deferred}{1}{}{}{}{Initial
462Gaussian parameters (velocity, width, amplitude) for profile
463fitting.}
464
465\requirement{Plotter change fit values}{Deferred}{1}{}{}{}
466{Change the parameter values of existing line profile
467fits, or channel ranges used for baseline fits.}
468
469\section{Functionality}
470
471\subsection{Import/export}
472
473The software needs a set of import/export functions to deal with a
474variety of data formats and to be able to exchange data with other
475popular packages. These functions should be flexible enough to allow
476the user to perform analysis functions in an different package and
477re-import the data (or vice versa). The import function must be
478modular enough to easily add new file formats when the need arises.
479To properly import data, extra information may have to be read from
480secondary calibration files (such as GTP, Gated Total Power, for 3~mm
481wavelength data taken with Mopra). The import functions should be
482flexible enough to gracefully handle data files with missing headers
483etc. They should also be able to make telescope and date specific
484corrections to the data (for ATNF observatories).
485
486The software must be able to read (import) the following file formats.
487
488\requirement{Read rpfits}{Done1}{}{}{}{}{The rpfits file format produced by
489 all current ATNF correlators.}
490
491\requirement{Read sdfits}{Done1}{}{}{}{}{SDFITS (currently written by {\tt SPC}).}
492
493\requirement{Read simple FITS}{Not started}{2}{}{}{}{Simple ``image'' FITS
494(used by CLASS}
495
496\requirement{Read historic formats}{Not started}{3}{}{}{}
497{Historic ATNF single dish formats (Spectra, SPC, SLAP). Possibly a
498set of routines to translate these formats to SDFITs would suffice.}
499
500\requirement{Read PSRFITS}{Deferred}{}{}{}{}{PSRFIT for pulsar spectroscopy.}
501
502\requirement{Read online data}{Not started}{1}{0.1d}{}{}
503{For online analysis, the software should be able to read an rpfits
504file which is is still currently open for writing by the telescope
505backend processor.}
506
507\requirement{Handle Doppler data}{Done1}{1}{}{}{}{Data which has been
508observed in either a fixed frequency or Doppler tracked fashion needs
509to be handled.}
510
511The software should be able to export the data in the following formats.
512
513\requirement{Write SDFITS}{Done1}{}{}{}{}{Single Dish FITS.}
514
515\requirement{Write simple FITS}{Done1}{}{}{}{}
516{Simple ``image'' FITS (as used by CLASS). It must be possible to to
517export multiple spectra simultaneously, using default file name and
518postfix.}
519
520\requirement{}{Removed}{}{}{}{}{}{In a format which can be imported by other popular
521 packages such as Class.
522
523\requirement{Write ASCIIs}{Done1}{}{}{}{}
524{Simple ASCIIs format, suitable for use with programs such as Perl,
525Python, SuperMongo etc.}
526
527\requirement{Header writing}{Started}{1}{0d}{}{}
528{The exported data should retain as much header data as possible. It
529should also be possible to request specific data be written in the
530desired form (B1950 coordinates, optical velocity definition etc).}
531
532\requirement{Import corrections}{Done1}{}{}{}{}
533{The import function should apply relevant corrections (especially
534those which are time dependent) to specific telescopes. See
535$\S$\ref{sec:issues} for a list of currently known issues.}
536
537\requirement{Append output files}{Not started}{1}{3d}{}{} {It must be possible
538to append spectra to existing output files, specifically sdfits and
539asap output files.}
540
541\subsection{Sky subtraction}
542\label{sec:skysubtraction}
543To remove the effects of the passband filter shape and atmospheric
544fluctuations across the band, sky subtraction must be performed on the
545data. The software must be able to do sky subtraction using both
546position switching (quotient spectra) and frequency switching
547techniques.
548
549\requirement{Quotient Spectra}{Done1}{}{}{}{}
550{\label{ref:skysub} Position switched sky subtraction should be
551implemented using the algorithm \medskip\reqeqn{T_{ref} \times
552\frac{S}{R} - T_{sig}} -- removes continuum\bigskip \reqeqn{T_{ref}
553\times \frac{S}{R} - T_{ref}} -- preserves continuum\medskip}
554
555\requirement{Arbitrary reference}{Not started}{2}{}{}{}
556{The user should be able to specify an arbitrarily complex
557reference/source order (which repeats), which can then be used to make
558perform multiple sky subtractions in parallel.}
559
560\requirement{Frequency switching}{Not started}{2}{}{}{}
561{Frequency switched sky subtraction should be supported. (Ref. Liszt,
5621997, A\&AS, 124, 183) }
563
564%\requirement{For wideband multibit sampled data it may be desirable or
565%even required to assume Tsys has a frequency dependency. Appropriate
566%sky subtraction algorithms will need to be investigated.}{3}
567
568\requirement{Pulsar off pulse quotient}{}{}{}{Deferred}{3}
569{For pulsar binned data, the (user specified) off pulse bins can be
570used as the reference spectra. Due to potentially rapid amplitude
571fluctuations, sky subtractions may need to be done on a
572integration basis.}
573
574Multibeam systems can observe in a nodding fashion (called MX mode at
575Parkes), where the telescope position is nodded between scans so that
576the source is observed in turn by two beams and a reference spectra
577for one beam is obtained while the other is observing the target source.
578
579\requirement{Multibeam MX mode}{Not started}{2}{}{}{}
580{For multibeam systems, it must be possible to perform sky subtraction
581with the source and reference in an alternate pair of beams}
582
583\subsection{Baseline removal}
584
585Baseline removal is needed to correct for imperfections in sky
586subtraction. Depending on the stability of the system, the residual
587spectral baseline errors can be small or quite large. Baseline removal
588is usually done by fitting a function to the (user specified) line
589free channels.
590
591\requirement{Baseline removal}{Done1}{}{}{}{}
592{The software must be able to do baseline removal by fitting a n'th
593order polynomials to the line free channels using a least squares
594method.}
595
596\requirement{Standing wave ripples}{Not started}{3}{}{}{}
597{Removal of standing wave ripples should be done by fitting a Sine
598function to the line free channels.}
599
600\requirement{Robust fitting}{Not started}{3}{}{}{}
601{``Robust'' fitting functions should be available, which are more
602tolerant to RFI.}
603
604\requirement{Auto-baseline}{Done1}{}{}{}{}
605{Automatic techniques for baselining should be investigated.}
606
607\subsection{Line Profile Fitting}
608
609The user will want to fit multicomponent line profiles to the data in
610a simple manner and be able to manipulate the exact fitting
611parameters.
612
613\requirement{Gaussian fitting}{Done1}{}{}{}{}
614{The software must be able to do multi-component Gaussian fitting of
615the spectra. The initial amplitude, width and velocity of each
616component should be able to be set by the user and specific values to
617be fit should be easily set.}
618
619\requirement{Chi squared}{Done1}{}{}{}{}
620{The reduce Chi squared (or similar statistic) of the fit should given
621to the user, so that they can easily see if adding extra components
622give a statistically significant improvement to the fit.}
623
624%\requirement{The fit parameters should be stored with the data so that
625%the user can work on multiple data sets simultaneously and experiment
626%with different fitting values. These values should be saved to disk
627%along with the data.}{1}
628
629\requirement{Fit multipol data}{}{}{}{Done1}{}
630{For multiple polarisation data, the individual stokes parameters or
631polarisation products should be fit independently.}
632
633\requirement{Export fit parameters}{Not started}{1}{1d}{}{}
634{There should be an easy way of exporting the fit parameter from
635multiple spectra, e.g. as an ASCII table.}
636
637\requirement{Constrained fitting}{Not started}{2}{}{}{}
638{It should be also possible to do constrained fitting of multiple
639hyperfine components, e.g. the NH$_3$ hyperfine components. (The
640constraints may be either the frequency separation of the individual
641components or the amplitude ratio etc.)}
642
643\subrequirement{Specific constrained fitting}{Not started}{1}{4d}{}{}
644{Before arbitrary constrained fitting is available, support for
645specific cases, such as the NH$_3$ hyperfine transition, should e
646added on a case-by-case basis.}
647
648\requirement{Edit fits parameters}{Done1}{}{}{}{}
649{It must be possible to alter the line profile fit parameter values by
650hand at any stage.}
651
652\requirement{Fix fit parameters}{Done1}{}{}{}{}
653{It must be possible to ``fix'' particular values of the line profile
654parameters, so that only subset of lines or (say) the width of a line
655is fit.}
656
657\requirement{Arbitrary line fitting}{Done1}{}{}{}{}
658{The software should allow hooks for line profile shapes other than
659Gaussian to be added in the future, possible user specified.}
660
661\requirement{Save fit parameters}{Done1}{}{}{}{}
662{The fitting parameters for functions which have been fit to the data
663(e.g. for baseline removal or Gaussian fits) should be retained as an
664integral part of the data and stored permanently on disk.}
665
666\requirement{Undo subtracted fits}{Not started}{3}{}{}{}
667{It should be possible to ``undo'' functions which have been
668subtracted from the data (e.g. baseline polynomials).}
669
670\requirement{Gaussian line area}{Not started}{1}{0.2d}{}{}
671{Optionally the area under a fitted Gaussian should be calculated for
672the user.}
673
674%\makenote{Should it be possible to attach multiple sets of fits to the
675%data (similar to CL tables in classic AIPS), so the user can
676%experiment with different ways of fitting the data?}
677
678%\makenote{Should calculations of rotational temperatures etc be
679%handled when fitting hyperfine components, or should the user be doing
680%this themselves?}
681
682\subsection{Calibration}
683
684The software should handle all basic system temperature (Tsys) and
685gain calibration as well as opacity corrections where relevant. The
686Tsys value should be contained in the rpfits files. The actual
687application of the T$_{\mbox{sys}}$ factor will be applied as part of
688the sky subtraction ($\S$\ref{sec:skysubtraction}). The units of Tsys
689recorded in the data may be either in Jy or Kelvin, which will affect
690how the data is calibrated. The rpfits file does {\em not} distinguish
691if the flux units are Kelvin or Janskys.
692
693\requirement{Gain-elevation}{Done1}{}{}{}{}
694{Gain elevation corrections should be implemented using a elevation
695dependent polynomial. The polynomial coefficients will be telescope
696and frequency dependent. They will also have a (long term) time
697dependence.}
698
699\requirement{User gain polynomial}{Done1}{}{}{}{}
700{The user may wish to supply their own gain polynomial.}
701
702\requirement{K-Jy conversion}{Done1}{}{}{}{}
703{When required by the user, the spectral units must be converted from
704Kelvin to Jansky. At higher (3mm) frequencies this conversion is often
705not applied. The conversion factor is\medskip \reqeqn{\mbox{Flux (Jy)}
706= \frac{T \times 2 k_b \times 10^{26}}{\eta A}},\medskip\\where $k_b$
707is Boltzmann's constant, A is the illuminated area of the telescope
708and $\eta$ is the efficiency of the telescope (frequency, telescope
709and time dependent)}
710
711\requirement{Scale Tsys}{Done1}{}{}{}{}
712{In some cases the recorded Tsys values will be wrong. There needs to
713be a mechanism to scale the Tsys value and the spectrum if the Tsys
714value has already been applied (i.e. a simple and consistent rescaling
715factor).}
716
717\requirement{Opacity}{Done1}{}{}{}{}
718{The data may need to be corrected for opacity effects, particularly
719at frequencies of 20~GHz and higher. The opacity factor to apply is
720given by\medskip\reqeqn{C_o = e^{\tau/cos(z)}}\medskip\\ where $\tau$
721is the opacity and z is the zenith angle (90-El). These corrections
722will generally be derived from periodic ``skydip'' measurements. These
723values will not be contained in the rpfits files, so there should be a
724simple way of the software obtaining them and interpolating in time
725(the user should not {\em have} to type them in, but may want
726to). Reading in an ASCIIs file which contains the skydip data along
727with a time-stamp would be one possibility.}
728
729\requirement{Tsys variation with freq}{Not started}{3}{}{}{}
730{For wideband, multibit observations, the software should have the
731option to handle Tsys which varies across the band. The exact
732implementation will have to be decided once experience is gained with
733the new Mopra digital filterbank. This will affect the sky subtraction
734algorithms (requirement \reqref{ref:skysub}).}
735
736%\makenote{Is the dependence of gain on frequency weak enough for one
737%set of coefficients for each receiver, or is a full frequency dependent
738%set of values needed?}
739
740%\makenote{Should it be possible to read ``correct'' Tsys values from
741%an external ascii file?}
742
743\subsection{Editing \& RFI robustness}
744
745In a data set with many observations, individual spectra may be
746corrupted or the data may be affected by RFI and ``birdies''. The user
747needs to be able to easily flag individual spectra or channels. This
748may affect other routines such as sky-subtraction, as this will
749disrupt the reference/source sequence.
750
751\requirement{Spectra flagging}{Started}{1}{1d}{}{}
752{The user must be able to set an entire spectra or part thereof
753(individual polarisation, IF etc) as being invalid.}
754
755\requirement{Channel flagging}{Started}{1}{0.5d}{}{}
756{The user must be able to indicate an individual spectral point or
757range of spectral points are invalid. This should be applied to an
758individual spectra, or set of spectra.}
759
760\subrequirement{Flagged channel plotting}{Done1}{1}{}{}{} {When plotting data
761with flagged spectral channels, the plotting should left a gap (blank)
762in the plotted data|}.
763
764\subrequirement{Flagged channel interpolation}{Not started}{2}{}{}{}
765{When plotting or processing data (e.g. quotient spectra), the users
766should be able to request that the values for flagged data are
767obtained by interpolation from good data either side of the flagged
768points.}
769
770\requirement{Plot average flux vs time}{Not started}{3}{}{}{}
771{The user should be able to plot the average spectral flux across the
772band, or part of the band, as a function of time and interactively
773select sections of data which should be marked as invalid (similar to
774IBLED in classic aips).}
775
776\requirement{Robust Fitting}{Duplicate}{2}{}{}{}
777{Where relevant, fitting routines etc should have the option of
778selecting RFI tolerant (``robust'') algorithms. This will require
779investigating alternate fitting routines other than the least-squares
780approach.}
781
782\requirement{Birdie finder}{Not started}{2}{}{}{}
783{A routine to automatically find birdies or RFI corrupted data and
784indicate the data as invalid would be useful.}
785
786\requirement{Handle flagged data}{Done1}{}{}{}{}
787{Other routines must be able to cope with portions of data which are
788marked as invalid.}
789
790\subsection{Spectra mathematics and manipulation}
791
792A flexible suite of mathematical operations on the spectra should be
793possible. This should include options such as adding, subtracting,
794averaging and scaling the data. For common operations such as
795averaging and smoothing, it must be simple for the user to invoke the
796function (i.e. not to have to start up a complex spectral
797calculator). Where it makes sense, it should be possible to manipulate
798multiple spectra simultaneously.
799
800The spectral manipulations which should be available are:
801
802\requirement{Add spectra}{Done1}{}{}{}{}{Add or subtract multiple spectra.}
803
804\requirement{Average spectra}{Done1}{1}{}{}{}
805{Averaging multiple spectra, with optional weighting based on Tsys,
806integration or rms.}
807
808\subrequirement{Average spectra with velocity shift}{Not started}{1}{0.2d}{}{}
809{If the velocity of the spectra to be averaged is different, the data
810should be aligned in velocity. The user should be able to turn this
811feature on or off.}
812
813\requirement{Robust averaging}{Not started}{2}{}{}{}
814{Various robust averaging possibilities (e.g. median averaging,
815clipped means etc) should be possible.}
816
817\requirement{Data re-binning}{Done1}{}{}{}{}
818{Re-sampling or re-binning of the data to a lower (or higher) spectral
819resolution (i.e. change the number of spectral points). The
820re-sampling factor may not necessarily be an integer.}
821
822\requirement{Velocity shift}{Done1}{}{}{}{}
823{It must be possible to shift the data in ``frequency/velocity''. This
824should include channel, frequency and velocity shifts of an arbitrary
825amount.}
826
827\requirement{Spectra smoothing}{Done1}{}{}{}{}
828{Spectral smoothing of the data. Hanning, Tukey, boxcar and Gaussian
829smoothing of variable widths should be possible.}
830
831\requirement{Spectra scaling}{Done1}{}{}{}{}{Scaling of the spectra.}
832
833\requirement{Spectra statistics}{Done1}{}{}{}{}
834{Calculate basic statistical values (maximum, minimum, rms, mean) on a
835range of spectral points. The range may not be contiguous. The
836calculated rms value should be retained with the spectra so it can be
837optionally used for weighted averaging of spectra.}
838
839\requirement{Line flux}{Not started}{2}{}{}{}
840{It must be possible to calculate the flux integral over a range of
841channels. The units should be Jy.km/s (or Kelvin.km/s). The channel
842range for the calculation should be specific via the GUI or CLI.}
843
844\requirement{Line width}{Not started}{2}{}{}{}
845{It must be possible to calculate the numerical ``width'' of a line
846(full width at half maximum type measurement). This should be
847calculated by specifying a channel range and finding the maximum value
848in this range and then finding the interpolated crossing point of the
849data as a user defined fraction of the maximum (default 50\%). The
850profile width and velocity mid-point should then be computed. If the
851profile shape is complex (e.g. double arch) with multiple crossing
852points of the fraction value, the minimum and maximum width values
853should be calculated. There should be the option of using a user
854specified ``maximum value''.}
855
856\requirement{Change rest frequency}{Done1}{}{}{}{}
857{The user must be able to easily change the rest-frequency to which
858the velocity is referenced.}
859
860\requirement{FFT filtering}{Not started}{3}{}{}{}
861{FFT filtering for high- and lowpass filtering and tapering.}
862
863\requirement{FFT to/from autocorrelation function}{Not started}{3}{}{}{}
864{It should be possible to FFT the data to and from power spectra to
865the autocorrelation function.}
866
867\requirement{Cross correlation}{Not started}{3}{}{}{}
868{The user may wish to compute the cross correlation function of two
869spectra. The result should be a standard ``spectra'', which can be
870displayed and analysed using other functions (max, rms etc).}
871
872\requirement{Spectral calculator}{Started}{1}{?}{}{}
873{Complex experiment specific processing can often be done using a
874series of the simple of basic functions. A spectral calculator options
875should be added to the CLI to perform a series of manipulations on a
876set of spectra.}
877
878The user may want to perform specific analysis on the data using the
879functionality above, but wish to do the manipulation between two
880polarisations or IFs. Allowing the functions to also, optionally,
881specify specific polarisations or IF would be an implementation and
882interface nightmare. The simplest solution is to allow the data to be
883``split'' into separate spectra.
884
885\requirement{Slice data}{Not started}{1}{10d}{}{} {It must be possible to
886take multi IF, multibeam or polarisation data and split out the a
887splice of individual spectral portions to form self contained
888spectra.}
889
890\requirement{Slice spectral channels}{Not started}{1}{0d}{}{} {It must be
891possible to select a range of spectral channels to form self contained
892spectra. The channel selection may be different for different IFs.}
893
894\requirement{Merge scantables}{Not started}{1}{5d}{}{}
895{It must be possible to append rows from one scantable onto another}
896
897\subsection{Polarimetry}
898
899The software must fully support polarmetric analysis. This includes
900calibration and basic conversions. Observations may be made with
901linear or circular feed and the backend may or may not compute the
902cross polarisation products. As such the software must cope with a
903variety of conversions. The software should be able to calculate
904stokes parameters with or without solving for leakage terms.
905
906%\makenote{It is debatable whether stokes I is the sum or average or
907%two dual polarisation measurements.}
908
909\requirement{Support polarimetry}{Started}{1}{?}{}{}
910{All functions on the data (calibration, sky subtraction spectral
911mathematics) must support arbitrary, multiple polarisation (linear,
912circular \& stokes and single, dual \& cross polarisations.}
913
914\requirement{Calculate stokes I}{Done1}{}{}{}{}
915{It must be possible to calculate stokes I from single or dual
916polarisation observations.}
917
918\requirement{Average mixed pol data}{Not started}{2}{}{}{}
919{Average a mixture of dual polarisation and single polarisation data
920and form average stokes I (e.g. for a long observation of a source, in
921which one polarisation is missing for some time.}
922
923\requirement{Calculate stokes}{Done1}{}{}{}{}
924{Full stokes parameters should be obtained from dual pol (linear or
925circular) observations where the cross polarisation products have been
926calculated.}
927
928%\requirement{If the observations used linear polarisations and the
929%cross polarisations were not computed, the source needs to be
930%observed with the feeds set at least 3 different parallactic angles
931%(note that if dual linear feeds are available, 2 orthogonal
932%parallactic angles are obtained at once). The Stokes parameters can be
933%solved using a least squares fit to the equation:
934%\reqeqn{Iu/2 + Ip * cos^2 (PA + p)},\\
935%where PA is the linear feed position angle, p is the polarisation
936%angle, Iu and Ip and the unpolarised and linearly polarised
937%intensity. {\em Stolen from SPC. I need to write this in more useful
938%language. Is this technique likely to be used anymore?.}}{}{}{}{3}
939
940\requirement{Compute stokes V without crosspol}{Not started}{2}{}{}{}
941{If dual circular polarisation measurements are taken, without
942computing the cross products, the software should still be able to
943compute stokes I and V.}
944
945\requirement{Polarisation leakages}{Not started}{3}{}{}{}
946{The software should be able to calculate leakage terms from a
947calibrator source and correct the data either before or after
948conversion to Stokes. (ref. Johnston, 2002, PASA, 19, 277)}
949
950\requirement{Calibrate position angle}{Not started}{3}{}{}{}
951{The software should be able to determine absolute position angle from
952a calibrator source and correct the data either before or after
953conversion to Stokes.}
954
955\requirement{Zeeman splitting}{Not started}{3}{}{}{}
956{Zeeman splitting factors should be derived from (previous) profile
957fitting and the left and right circular polarisations. The velocity
958shift varies linearly with the magnetic field, but the scaling factor
959depends on the molecule and transition. Scaling factor for common
960transitions should be known by the software and the user able to enter
961factors for less common transitions. Correctly identifying Zeeman
962pairs is crucial in getting the correct result. The software should
963attempt to make an initial guess of pairs (based on component velocity
964and width) but make the user confirm and override the pairing if
965required.}
966
967\subsection{Data Selection}
968While the software is running the user will usually have loaded
969multiple (possibly many) spectra each of which may have multiple IFs,
970data from multiple beams and multiple polarisations. The user will
971want to be able to quickly flip from considering one spectra to
972another and, where relevant, want to perform parallel processing on
973multiple spectra at once (e.g. baselining a sequence of on/off
974observations of the same source which will later be averaged
975together).
976
977\requirement{Spectra selection}{Started}{1}{0d}{}{}
978{The software needs an easy-to-use mechanism to select either
979individual or multiple spectra for viewing, parallel processing
980etc.}
981
982\requirement{Beam/IF selection}{Started}{1}{0d}{}{}
983{An easy-to-use mechanism to select individual IFs, beams or
984polarisations is needed.}
985
986\requirement{Interactive channel selection}{Started}{1}{}{}{}
987{\label{ref:chansel} The range of spectral points to use for baseline
988removal, statistical calculations, RFI editing, analysis etc must be
989easily set by the user from both the CLI and GUI. From the CLI there
990must be the option of setting the range using a variety of units
991(channel number, velocity, frequency). The selection range will
992probably not be a contiguous set of channels, but many sets of
993disjoint channel ranges. For some tasks (such as baseline subtraction
994and statistical values), the channel range should be retained and be
995available as a plot overlay.}
996
997\requirement{Auto-identify reference spectra}{Not started}{1}{5d+}{}{}
998{When performing sky subtraction on many spectra simultaneously, the
999software should have a mechanism for identifying ``on'' and ``off''
1000spectra and automatically selecting the signal and quotient
1001spectra. The algorithm needs to cope with on/off/on/off sequences as
1002well as off/on/on/off. If an individual quotient spectra has been
1003marked as invalid, an alternative should be found. User specified
1004preference such as ``closest in time'' to ``first reference before
1005source'' should be accommodated.}
1006
1007\requirement{Select source via header values}{Started}{1}{}{}{}
1008{The software should be able to select sets of sources based on simple
1009regular expression type filtering (wild cards) on a range of header
1010values. }
1011
1012\subrequirement{Select on source name}{Done1}{1}{}{}{}
1013{The use should be able to select dana on source name, e.g G309$*$ or
1014G309$*$w}
1015
1016\subrequirement{Select on molecule}{Done1}{2}{}{}{}
1017{The use should be able to select data on molecule name, e.g. NH3$*$.}
1018
1019\subsection{Plugins}
1020
1021\requirement{Plugins}{Started}{1}{?}{}{}
1022{The package should support ``plugins'', user definable
1023functions for specific processing. The plugin code must have full
1024access (read/write) to the spectra data and headers.}
1025
1026\requirement{Plugins can reduce dimensions}{Not started}{2}{}{}{}
1027{Plugins need to be able to create ``derived'' spectra with reduced
1028 dimensions (i.e. less beams, IFs, polarisations or spectral
1029 channels)}
1030
1031\requirement{Simulated data}{Not stated}{3}{}{}{}
1032{The user should be able to create new spectra which the software
1033treats the same as the original data. This includes full specification
1034of the header items.}
1035
1036\subsection{Pipelining}
1037
1038\requirement{Pipelining}{Done1}{}{}{}{}
1039{Some sort of pipelining mode is required. This would involve doing a
1040quotient spectra, applying appropriate calibration and possibly
1041fitting a Gaussian to any lines present.}
1042
1043\subsection{Methanol Multibeam Survey}
1044
1045The software may need to support reduction of data from the methanol
1046multibeam project. If so the pipelining will need to be flexible and
1047powerful enough to support this.
1048
1049\subsection{Miscellaneous functionality}
1050
1051\requirement{Position fitting}{Not started}{2}{}{}{}
1052{The software should be able to take a simple ``grid'' of observations
1053(normally a set of observations in a cross pattern on the sky) and,
1054for a subset of channels, fit the position of the emission. The fit
1055positions should be either plotted on the screen or exported in a
1056simple ASCIIs form.}
1057
1058\requirement{Kinematic distance}{Not started}{3}{}{}{}
1059{The kinematic distance of a source should be calculated using basic
1060Galactic rotation models. Multiple Galactic rotation models must be
1061supported and a mechanism for easily adding more.}
1062
1063\requirement{Plot sigma errors on spectra}{Not started}{3}{}{}{}
1064{For 1420 MHz observations of HI, the rms (Tsys) values vary
1065significantly across the band. The software should be able to compute
1066the rms as a function of frequency across the spectra from the
1067off-pulse data and then be able to plot n-sigma error bars on the
1068spectra.}
1069
1070\requirement{Simple Mapping}{Not started}{3}{}{}{}
1071{It should be possible to take a selection of calibrated spectra which
1072are then passed to the ``Gridzilla'' program to produce an image
1073cube. Analysis of this cube would be done using external programs
1074(e.g. Miriad, aips++)}
1075
1076\section{Help}
1077
1078\requirement{Built in help}{Done1}{}{}{}{}
1079{There should be built-in and web-based documentation, which can be
1080easily kept up-to-date}
1081
1082\requirement{Cookbook}{Done1}{}{}{}{}
1083{A short and simple end-to-end cookbook for basic data analysis should
1084be available.}
1085
1086\requirement{Programmers Documentation}{Not started}{2}{}{}{}
1087{There should be documentation aimed at astronomers wishing to write
1088there own scripts, detailing the methods needed and how to get low
1089level access to the data.}
1090
1091\section{Data and meta-data}
1092
1093\requirement{Handle multi dimensional data}{Done1}{}{}{}{}
1094{The software must be capable of handling multi-IF (potentially dozens
1095of IFs) and multi-beam data with arbitrary polarisation (e.g. single
1096pol, dual pol, full stokes etc).}
1097
1098\requirement{Handle pulsar data}{Deferred}{}{}{}{}
1099{The software should handle pulsar binned data for pulsar absorption
1100experiments.}
1101
1102\subsection{History}
1103
1104\requirement{History}{Done1}{}{}{}{}
1105{A user viewable history of data processing steps should be kept as
1106part of the data. Where possible this should be retained when data is
1107imported from other packages.}{
1108
1109\requirement{Convert history to script}{Not started}{2}{}{}{}
1110{It should be possible to use the history information to create
1111template pipeline scripts for batch processing.}
1112
1113\subsection{Multiple IFs}
1114
1115\requirement{Transparently handle multi-IF data}{Done1}{}{}{}{}
1116{If multiple IFs are present (currently Tidbinbilla can produce two
1117IFs and the new wideband spectrometer for Mopra may have dozens of
1118IFs) the software should handle the data transparently. Potentially
1119each IF may have a significantly different sky frequency and be
1120observing a different molecule or transition with a different rest
1121frequency. From the users point of view, simultaneously obtained IFs
1122should be kept within the same ``container'' (not split into a myriad
1123of separate ``container'').}
1124
1125\requirement{IFs with different number of spectral channels}{Not started}{1}{}{}{}
1126{Separate IFs may have a different number of spectral channels.}
1127
1128\subsection{Multibeam}
1129
1130\requirement{Handle multibeam data}{Done1}{}{}{}{}
1131{Basic handling of multibeam data should be possible (ie in general
1132each beam will be treated as a separate observation, but all within
1133the same container). The user should be able to view or process either
1134individual beams or all beams in parallel.}
1135
1136\requirement{Multibeam simultaneous reference/signal}{Not started}{3}{}{}{}
1137{The use of a single beam observing a source and the rest of the beams
1138as reference beams for sky-subtraction should be investigated.}
1139
1140\subsection{Robust fitting}
1141
1142\requirement{Retain raw correlator integrations}{Done1}{}{}{}{}
1143{If robust fitting using median filtering is used, then the individual
1144integrations from the observations should {\em not} be averaged when
1145the data is imported, but retained within a single
1146container. Inspection of this data should be optionally of the
1147averaged or individual data.}
1148
1149\subsection{Coordinate frames and units}
1150
1151\requirement{Flexible coordinate frames}{Done1}{}{}{}{}
1152{Coordinate frames and unit selection and handling needs to be
1153flexible and relatively transparent to the user (i.e. if the users
1154preference is for LSRK velocities, they do not need to worry about the
1155reference frame in which the data was observed).}
1156
1157\requirement{Specific reference frames}{Done1}{}{}{}{}
1158{At a minimum the following reference frames and conventions should be
1159handled: \setlength{\parindent}{0pt}
1160
1161\smallskip
1162\anitem{Position}{(RA,Dec) in J2000 \& B1950 (as well as other
1163 arbitrary epochs), Galactic, (Az,El).}
1164
1165\anitem{Frequency}{Velocity (Topocentric, Geocentric, Barycentric,
1166 Heliocentric, kinematical LSR, dynamical LSR, Rest), Frequency
1167 (MHz, GHz), channel number.}
1168
1169\anitem{Velocity}{ Optical, Radio, Relativistic.}
1170
1171\anitem{Flux}{ Jansky, Kelvin (mJy etc).}}
1172
1173\requirement{Data units and frames properly labelled}{Done1}{}{}{}{}
1174{All data should be internally labelled with the appropriate
1175 coordinate frame and units. If this information is ambiguous for some
1176 reason, it should be set when the data is imported and the user
1177 should not have to worry about it again.}
1178
1179\requirement{Current reference frames clear to user}{Done1}{}{}{}{}
1180{It should be clear to the user what coordinate frame (velocity,
1181position etc) the data is being presented as.}
1182
1183\requirement{Positional Reference Frame}{Not started}{1}{0.2d}{}{} {The user
1184should be able to specify the reference frame (Epoch,Equinox etc) for
1185which is used for exporting data, simple mapping output etc. J2000,
1186B1950 and Galactic should be supported. The default should be the frame
1187in what the data was recorded.}
1188
1189\requirement{Non-conformist Positional Reference Frame}{Not started}{2}{}{}{}
1190{Non-confirmist positional frames such as Az-El should be supported.}
1191
1192\subsection{Meta-data}
1193
1194A comprehensive set of header data should be read from the input data
1195files. In general all meta-data available in the rpfits file should be
1196retained. The user may wish to enter some specific values by hand.
1197
1198\requirement{View and edit header data}{Started}{1}{?}{}{}
1199{All header data should be viewable and editable by the user. This
1200includes changes such as scaling the given Tsys values.}
1201
1202\requirement{Missing header data}{Done1}{}{}{}{}
1203{Missing header data should be handled gracefully, i.e. the software
1204should fill the values with ``blanks'' and be able to continue to
1205process the data if possible.}
1206
1207\requirement{User add missing header data}{Not started}{2}{}{}{}
1208{The user must be able to add missing header data, which is not
1209present in the RPFITs file. It must be possible to add the same header
1210data to multiple scans simultaneously.}
1211
1212\extendedrequirement{Itemised header items}{Started}{1}{}{}{}
1213{The following header data would be required per scan:
1214\begin{itemize}
1215 \item Source name
1216 \item Scan type (signal or reference)
1217 \item Integration time
1218 \item Scan length (actual time of observation, $\ge$ integration time)
1219 \item Telescope
1220 \item UT time and date of observation
1221 \item Telescope elevation of observation
1222 \item Parallactic angle
1223 \item Beam size
1224 \item Scan ID
1225 \item Observer
1226 \item Project
1227 \item Polarisation
1228 \item Receiver
1229 \item Telescope coordinates
1230 \item Weather info (temperature, pressure, humidity)
1231 \item User axis display preference (LSR velocity, frequency etc).
1232\end{itemize}
1233}
1234
1235\extendedrequirement{IF header items}{Started}{1}{}{}{}
1236{\label{req:if}
1237The following header data is required for each IF, beam etc:
1238\begin{itemize}
1239\item Source coordinates and coordinate frame
1240\item Frequency/velocity axis definition and type
1241\item System Temperature
1242\item Beam number
1243\item Molecule rest frequency$^\dagger$
1244\item Molecular name$^\dagger$
1245\item Molecular transition$^\dagger$
1246\item Molecular formula$^\dagger$
1247\end{itemize}
1248}
1249
1250\requirement{Pretty print formula}{Not started}{3}{}{}{}
1251{The molecular formula could be stored with embedded superscripted and
1252subscripted symbols for ``pretty'' printing on the plotted, but
1253printed in plain text on the CLI or in ASCIIs output}
1254
1255Some molecular line rest-frequencies are close enough that two or more
1256molecules or transitions may be observed in a single IF. Typical
1257examples include the 1665/1667~MHz OH maser pair, NH$_3$ transitions,
1258and many observations in the 3~mm band.
1259\vspace{\parskip}
1260
1261\requirement{Multiple rest frequencies per IF}{Not started}{2}{}{}{}
1262{The software should optionally support multiple lines per IF, by
1263storing a set of rest frequencies per IF, rather than a single
1264value. The header values in requirement \reqref{req:if} marked with a
1265$\dagger$ would all have to be stored as an array of values rather
1266than a scalar. A simple mechanism must be possible to change the
1267currently ``active'' rest-frequency.}
1268
1269\section{Installation}
1270
1271\requirement{Easy installation}{Started}{1}{?}{}{}
1272{It must be possible for astronomers to install the software at their
1273own institute with either a moderate amount of OS experience or some
1274help from the local system administrators. This includes installation
1275on a central ``NFS'' server as well as local desktops.}
1276
1277\requirement{Linux Support}{Started}{1}{3d}{}{}
1278{The software must run on major flavours of Linux
1279(Fedora/Redhat, Debian, etc).}
1280
1281\subrequirement{Solaris Support}{Started}{1}{?}{}{}
1282{The software must run on Solaris}
1283
1284\requirement{Run on laptop}{Done1}{}{}{}{}
1285{It must be possible for users to install the software on their
1286laptops and run with no network connection.}
1287
1288\requirement{Easy upgrade}{Done1}{}{}{}{}
1289{It should be relatively easy to upgrade to the latest version of the
1290software.}
1291
1292\requirement{MacOS/X support}{Not started}{1}{3+d}{}{}
1293{The software should run on MacOS/X}
1294
1295\requirement{Windows support}{Not started}{3}{}{}{}
1296{It would be desirable for the software to run on Windows.}
1297
1298\section{Known Issues}
1299\label{sec:issues}
1300The following issue are known problems with the data from ATNF
1301telescopes, which probably should be automatically corrected for if at
1302all possible. The best place to do this is while loading the data.
1303
1304\subsection{General}
1305
1306\begin{itemize}
1307 \item All polarisations in the RPFITS files are labelled as
1308 XX/YY. These need to be relabelled as LL/RR when appropriate.
1309\end{itemize}
1310
1311\subsection{Mopra}
1312
1313\begin{itemize}
1314\item Data obtained in 2002 \& 2003 (and probably before) have an
1315 error in the frequency headers (this may be corrected by an external
1316 program). \makenote{Nedd Ladd}
1317
1318\item The (RA,Dec) positions in the data file are in date coordinates
1319 not J2000. This causes problems for packages like Class when
1320 averaging the data. \makenote{Maria Hunt}
1321
1322\item It is possible Tsys calibration is inconsistent currently.
1323 \makenote{Cormac Purcell??}
1324
1325\end{itemize}
1326
1327\subsection{Parkes}
1328
1329\begin{itemize}
1330\item For pulsar data the automatic gain control is disabled. This
1331means the nominal Tsys measurement does not change and Tsys per
1332integration is encoded in a non-standard way. \makenote{Simon
1333Johnston}
1334\end{itemize}
1335
1336\subsection{Tidbinbilla}
1337
1338\begin{itemize}
1339\item All 20-GHz data is calibrated in flux units of Kelvin.
1340\item Elevation is not written into the rpfits file.
1341\end{itemize}
1342
1343
1344\section{Requirements Matrix}
1345
1346\begin{longtable}{|l|l|l|c|l|}
1347
1348\hline
1349\bf Requirement & & \bf Status & \bf Priority & \bf Effort \\
1350\hline
1351\endhead
1352\hline
1353\endfoot
1354\input{reqsum.tex}
1355
1356\end{longtable}
1357
1358
1359\end{document}
Note: See TracBrowser for help on using the repository browser.