[769] | 1 | \documentclass[11pt]{article} |
---|
| 2 | \usepackage{a4} |
---|
| 3 | \usepackage{calc} |
---|
| 4 | \usepackage{smartref} |
---|
| 5 | \usepackage[dvips]{graphicx} |
---|
| 6 | |
---|
| 7 | % Adjust the page size |
---|
| 8 | \addtolength{\oddsidemargin}{-0.4in} |
---|
| 9 | \addtolength{\evensidemargin}{+0.4in} |
---|
| 10 | \addtolength{\textwidth}{+0.8in} |
---|
| 11 | |
---|
| 12 | \setlength{\parindent}{0mm} |
---|
| 13 | \setlength{\parskip}{1ex} |
---|
| 14 | |
---|
| 15 | |
---|
| 16 | \title{ATNF Single Dish Spectral Line Software Requirements } |
---|
| 17 | \author{Chris Phillips \& Malte Marquarding} |
---|
| 18 | |
---|
| 19 | \newcounter{requirement} |
---|
| 20 | \addtoreflist{requirement} |
---|
| 21 | \newcommand{\reqref}[1]{R\ref{#1}-\requirementref{#1}} |
---|
| 22 | |
---|
| 23 | \newcommand{\makenote}[1]{{\bf \tt \em#1}} |
---|
| 24 | |
---|
| 25 | \newcommand{\anitem}[2]{\smallskip \parbox[t]{2cm}{#1}\parbox[t]{\textwidth-2cm}{#2}} |
---|
| 26 | |
---|
| 27 | \newcommand{\showreqcounter}{{\stepcounter{requirement} |
---|
| 28 | \bf R\arabic{section}.\arabic{subsection}-\arabic{requirement}}} |
---|
| 29 | |
---|
| 30 | \newcommand{\requirement}[2]{ |
---|
| 31 | \hspace*{2mm}\begin{minipage}{\textwidth-2mm} |
---|
| 32 | \setlength{\parindent}{-2mm} |
---|
| 33 | \showreqcounter\ #1 \\ |
---|
| 34 | \hspace*{1cm} {\em Priority #2} |
---|
| 35 | \end{minipage} |
---|
| 36 | } |
---|
| 37 | |
---|
| 38 | \newcommand{\extendedrequirement}[2]{ |
---|
| 39 | \hspace*{2mm}\begin{minipage}{\textwidth-2mm} |
---|
| 40 | \setlength{\parindent}{-2mm} |
---|
| 41 | \showreqcounter\ #1 |
---|
| 42 | \hspace*{1cm} {\em Priority #2} |
---|
| 43 | \end{minipage} |
---|
| 44 | } |
---|
| 45 | |
---|
| 46 | \newcommand{\reqeqn}[1]{\\\hspace*{1cm} $#1$} |
---|
| 47 | |
---|
| 48 | \let\oldsection\section |
---|
| 49 | \renewcommand{\section}[1]{\setcounter{requirement}{0}\oldsection{#1}} |
---|
| 50 | |
---|
| 51 | \let\oldsubsection\subsection |
---|
| 52 | \renewcommand{\subsection}[1]{\setcounter{requirement}{0}\oldsubsection{#1}} |
---|
| 53 | |
---|
| 54 | \begin{document} |
---|
| 55 | |
---|
| 56 | \maketitle |
---|
| 57 | |
---|
| 58 | \section{Introduction} |
---|
| 59 | |
---|
| 60 | The spectral line single-dish software {\tt spc} at the ATNF has |
---|
| 61 | become increasingly difficult to maintain. There also have been many |
---|
| 62 | requests for features which are not possible to implement without |
---|
| 63 | major change to this package. The interface is based on outdated |
---|
| 64 | operating systems and programming languages. The decision was made to |
---|
| 65 | replace {\tt spc} with a new package which supports existing and |
---|
| 66 | future ATNF single-dish instrumentation. A survey of users was taken |
---|
| 67 | into account creating this requirements document. |
---|
| 68 | |
---|
| 69 | \section{Scope} |
---|
| 70 | |
---|
| 71 | The software should be able to process all spectral line single-dish |
---|
| 72 | observations from ATNF telescopes (Parkes, Mopra \& Tidbinbilla). This |
---|
| 73 | includes reading the data produced by the telescope, calibration and |
---|
| 74 | reduction of the data and basic analysis of the data such as fitting |
---|
| 75 | line profiles. |
---|
| 76 | |
---|
| 77 | It has been assumed that the following processing is out of the scope |
---|
| 78 | of the new software. |
---|
| 79 | \begin{itemize} |
---|
| 80 | \item Raster or ``on-the-fly'' mapping (This is handled by |
---|
| 81 | ``livedata'' and gridzilla). |
---|
| 82 | \item Very complex or specific data processing. (A route into |
---|
| 83 | Class\footnote{Part of the GLIDAS software package, produced by |
---|
| 84 | Institut de Radio Astronomie Millime\'trique http://www.iram.fr} |
---|
| 85 | should be available for advanced processing). |
---|
| 86 | %%TODO%% give example |
---|
| 87 | \item Continuum data. |
---|
| 88 | \item Pulsar timing observations. |
---|
| 89 | \end{itemize} |
---|
| 90 | |
---|
| 91 | \section{Priorities} |
---|
| 92 | |
---|
| 93 | Requirements have been given a value of 0 to 3. The ``0'' priority |
---|
| 94 | functions will be implemented in a demonstrator version of the |
---|
| 95 | software (with no GUI interface). The other requirements will be |
---|
| 96 | implemented mainly depending on priority, with ``1'' the |
---|
| 97 | highest. Priority 3 and some priority 2 requirements will probably not |
---|
| 98 | get implemented in the first released version of the software. |
---|
| 99 | |
---|
| 100 | \section{User Interface} |
---|
| 101 | |
---|
| 102 | The user interface (UI) is the most important part of a single dish |
---|
| 103 | processing package, but probably the most difficult to get right. The |
---|
| 104 | UI for this software will consist of three parts. |
---|
| 105 | \begin{itemize} |
---|
| 106 | \item A graphical user interface (GUI). |
---|
| 107 | \item An interactive command line interface (CLI). |
---|
| 108 | \item A scriptable interface for batch processing. |
---|
| 109 | \end{itemize} |
---|
| 110 | |
---|
| 111 | The CLI and scriptable interface may essentially be the same. |
---|
| 112 | |
---|
| 113 | The software does not {\em need} to be able to run solely from a |
---|
| 114 | ``vt100'' style terminal. It can be assumed that the user is running |
---|
| 115 | the software from within a windowed (i.e. X11) environment. This will |
---|
| 116 | mean it will not necessarily be possible to run the software remotely |
---|
| 117 | over a slow network connection (e.g. internationally or from home). |
---|
| 118 | Where possible, operations on the data should be possible from all |
---|
| 119 | three aspects of the user interface. |
---|
| 120 | |
---|
| 121 | The user interface needs to be implemented so that the user can easily |
---|
| 122 | and transparently work on spectra either one at a time or by |
---|
| 123 | processing multiple spectra in parallel. This means there must be an |
---|
| 124 | easy way to select specific or multiple spectra to display or process. |
---|
| 125 | |
---|
| 126 | \subsection{Graphical User Interface} |
---|
| 127 | |
---|
| 128 | The GUI is intended to be the main interactive interface with the |
---|
| 129 | software. |
---|
| 130 | |
---|
| 131 | \smallskip |
---|
| 132 | \requirement{It should be simple, intuitive and |
---|
| 133 | uncluttered. Specifically, use of many windows simultaneously should |
---|
| 134 | be discouraged, as should hiding functionality behind layers of dialog |
---|
| 135 | boxes.}{1} |
---|
| 136 | |
---|
| 137 | \requirement{The plotting window should be a major component of the GUI |
---|
| 138 | control, not a separate isolated window.}{1} |
---|
| 139 | |
---|
| 140 | \requirement{The interface should use minimal ``always visible'' |
---|
| 141 | controls, with use of pull down menus and maybe a toolbar for |
---|
| 142 | frequency used functions. }{1} |
---|
| 143 | |
---|
| 144 | \requirement{Keyboard shortcuts should be available.}{2} |
---|
| 145 | |
---|
| 146 | \requirement{Most user preferences (i.e. keywords in the CLI) should |
---|
| 147 | be presented in a popup, tabbed, dialog box.}{2} |
---|
| 148 | |
---|
| 149 | \requirement{When performing line profile fitting, a spreadsheet type |
---|
| 150 | window should be viewable which shows the current parameter values |
---|
| 151 | (amplitude, velocity etc) for each line fitted and allow the user to |
---|
| 152 | change these parameters or set the current value as fixed. This gui |
---|
| 153 | should stay synchronised with any CLI changes to these values.}{2} |
---|
| 154 | |
---|
| 155 | \subsection{Command Line Interface} |
---|
| 156 | |
---|
| 157 | \requirement{While the GUI should be the main interface for new users |
---|
| 158 | and for basic manipulation, some tasks can be more efficiently |
---|
| 159 | performed using a CLI. A virtual CLI could be integrated as part of |
---|
| 160 | the GUI.}{1} |
---|
| 161 | |
---|
| 162 | \requirement{The CLI should have a keyword/argument form and never |
---|
| 163 | prompt the user for specific values (the user should be able to change |
---|
| 164 | values which are retained until they wants to change them again).}{1} |
---|
| 165 | |
---|
| 166 | \requirement{The CLI should be case insensitive and accept minimum |
---|
| 167 | matching and short forms of keywords.}{2} |
---|
| 168 | |
---|
| 169 | \requirement{The user must be able to quickly and easily see from the |
---|
| 170 | command line the available routines and keywords which affect it, so |
---|
| 171 | they can see which parameters may need changing.}{1} |
---|
| 172 | |
---|
| 173 | \subsection{Scripting} |
---|
| 174 | |
---|
| 175 | \requirement{It must be possible to run the software in a scripting |
---|
| 176 | mode. This would be to process large amounts of data in a routine |
---|
| 177 | manner and also to automatically reproduce specific plots etc (So the |
---|
| 178 | scripting must have full control of the plotter). Preferably the |
---|
| 179 | scripting ``language'' and the CLI would be the same. }{1} |
---|
| 180 | |
---|
| 181 | \requirement{It would be worthwhile having a method to auto-generate |
---|
| 182 | scripts (for reduction or plotting) from current spectra history, or |
---|
| 183 | some similar method.}{3} |
---|
| 184 | |
---|
| 185 | \section{Plotter} |
---|
| 186 | |
---|
| 187 | The plotter should be fully interactive and be an integral part of the |
---|
| 188 | GUI and software interface. |
---|
| 189 | |
---|
| 190 | \requirement{It must be able to produce plots of publishable |
---|
| 191 | quality. This includes being able to specify line thickness, character |
---|
| 192 | size, colours, position of axis ticks, axis titles etc and producing |
---|
| 193 | hard copies in postscript and .png format.}{0} |
---|
| 194 | |
---|
| 195 | \requirement{It must be possible to flexibly select the data to plot |
---|
| 196 | (e.g. Tsys vs time etc as well as plots such as amplitude vs channel |
---|
| 197 | number or velocity). Preferably any of the header values for a |
---|
| 198 | selection of scans could be plotted on a scatter plot (e.g. Tsys vs |
---|
| 199 | elevation)}{2} |
---|
| 200 | |
---|
| 201 | \requirement{It must be possible to overlay multiple spectra on a |
---|
| 202 | single plot using different colours and/or different line |
---|
| 203 | styles. (Including multiple stokes data and multiple IFs).}{1} |
---|
| 204 | |
---|
| 205 | \requirement{It must be possible to plot either the individual |
---|
| 206 | integrations (in either a stacked fashion, or using a new subplot |
---|
| 207 | per integration) or some type of average of all the integrations in |
---|
| 208 | a scan.}{2} |
---|
| 209 | |
---|
| 210 | \requirement{Multi-panelling of spectra in an n$\times$m size grid. If |
---|
| 211 | more spectra than can fit on the plot matrix are to be plotted, then |
---|
| 212 | it must be possible to step back and forth between the viewable |
---|
| 213 | spectra (i.e. ``multi-page'' plots). It must be possible to quickly |
---|
| 214 | and easily change the number of plots per page, and define the ``n'' |
---|
| 215 | and ``m'' values.}{1} |
---|
| 216 | |
---|
| 217 | \requirement{When using multi-panelling, it should be possible to |
---|
| 218 | easily change the display to flip between a single spectra display |
---|
| 219 | and multi-panels display (i.e. zoom into a specific sub-window).}{3} |
---|
| 220 | |
---|
| 221 | \requirement{It must be possible to interactively zoom the plot |
---|
| 222 | (channel range selection and amplitude of the spectra etc.) This |
---|
| 223 | includes both GUI control of the zooming as well as command line |
---|
| 224 | control of either the zoom factor or directly specifying the zoom |
---|
| 225 | bounds. }{1} |
---|
| 226 | |
---|
| 227 | \requirement{On a single plot, it should be possible to plot the full |
---|
| 228 | spectrum and a zoomed copy of the data (using a different lie style) |
---|
| 229 | to see weak features. The user must be able to specify the zoom |
---|
| 230 | factor.}{3} |
---|
| 231 | |
---|
| 232 | \requirement{Optionally when stacking multiple spectral plots in one |
---|
| 233 | subwindow, a (user definable) offset in the ``y'' direction should |
---|
| 234 | be added to each subsequent spectra.}{2} |
---|
| 235 | |
---|
| 236 | \requirement{The plotter should automatically update to reflect user |
---|
| 237 | processing, either from the CLI or GUI. The user should have to option |
---|
| 238 | to turn this feature off if they so wish.}{2} |
---|
| 239 | |
---|
| 240 | \requirement{It should be possible to plot individual integrations |
---|
| 241 | (possibly from multiple scans) in a ``waterfall'' plot. This is an |
---|
| 242 | image based display, where spectral channel is along the x-axis of the |
---|
| 243 | plot, time (or integration number) along the y-axis and greyscale or |
---|
| 244 | colour represent the amplitude of spectra. Interactive zooming and |
---|
| 245 | panning of this image should be supported. }{3} |
---|
| 246 | |
---|
| 247 | \requirement{When plotting ``waterfall'' plots, it should be possible |
---|
| 248 | to interactively select regions or points and mark them as invalid |
---|
| 249 | (i.e. to remove RFI affected data). The plotter should also show the |
---|
| 250 | time/velocity of the pixel beneath the cursor.}{3} |
---|
| 251 | |
---|
| 252 | \requirement{It should be possible to export the ``waterfall'' plot |
---|
| 253 | images as a FITs file, for user specific analysis.}{3} |
---|
| 254 | |
---|
| 255 | \requirement{Line markers overlays, read from a catalogue should be |
---|
| 256 | optionally available. This would include the full Lovas catalogue, |
---|
| 257 | the JPL line catalogue, radio recombination lines and a simple user |
---|
| 258 | definable catalogue. The lines would be Doppler corrected to the |
---|
| 259 | line velocity. The user must be able to plot just a sub-section of |
---|
| 260 | the lines in any specific catalogue (to avoid clutter).}{2} |
---|
| 261 | |
---|
| 262 | \requirement{Optionally plot fitted functions (e.g line profiles or |
---|
| 263 | baseline fit). If multiple components (e.g. Gaussians) have been |
---|
| 264 | fit, it should be possible to show the individual functions or the |
---|
| 265 | sum of the components}{1} |
---|
| 266 | |
---|
| 267 | \requirement{It should be possible to plot the residual data with or |
---|
| 268 | without subtraction of fit functions. This includes plotting the |
---|
| 269 | spectra with or without baseline removal and the residual after |
---|
| 270 | subtracting Gaussian fits. The default should be to plot the data |
---|
| 271 | with baseline subtracted but profile fits not subtracted.}{2} |
---|
| 272 | |
---|
| 273 | \requirement{Basic header data (source name, molecule, observation |
---|
| 274 | time etc) should be optionally shown, either on the plot or next to |
---|
| 275 | it. This may either consist of a set of values, or only one or two |
---|
| 276 | values the user specifically wants to see (source name and molecule, |
---|
| 277 | for example). Preferably the user would be able to define where on |
---|
| 278 | the plot the header info would appear.}{2} |
---|
| 279 | |
---|
| 280 | \requirement{Optionally, relevant data such as the current mouse |
---|
| 281 | position should be displayed (maybe with a mode to display an |
---|
| 282 | extended cross, horizontal or vertical line at the current cursor |
---|
| 283 | position).}{2} |
---|
| 284 | |
---|
| 285 | \requirement{The user should be able to define simple |
---|
| 286 | annotations. This would include text overlay and probably simple |
---|
| 287 | graphics (lines, arrows etc).}{3} |
---|
| 288 | |
---|
| 289 | The user must be able to use the plotter window to interactively set |
---|
| 290 | initial values and ranges used for fitting functions etc. The use of |
---|
| 291 | keyboard ``shortcuts'' or other similar ``power user'' features should |
---|
| 292 | be available to save the time of experienced users. |
---|
| 293 | |
---|
| 294 | The plotter should be used to set the following values: |
---|
| 295 | |
---|
| 296 | \requirement{Range of spectral points needed for specific tasks (See |
---|
| 297 | requirement \reqref{ref:chansel})}{1} |
---|
| 298 | |
---|
| 299 | \requirement{Initial Gaussian parameters (velocity, width, amplitude) |
---|
| 300 | for profile fitting.}{1} |
---|
| 301 | |
---|
| 302 | \requirement{Change the parameter values of existing line profile |
---|
| 303 | fits, or channel ranges used for baseline fits.}{3} |
---|
| 304 | |
---|
| 305 | \section{Functionality} |
---|
| 306 | |
---|
| 307 | \subsection{Import/export} |
---|
| 308 | |
---|
| 309 | The software needs a set of import/export functions to deal with a |
---|
| 310 | variety of data formats and to be able to exchange data with other |
---|
| 311 | popular packages. These functions should be flexible enough to allow |
---|
| 312 | the user to perform analysis functions in an different package and |
---|
| 313 | re-import the data (or vice versa). The import function must be |
---|
| 314 | modular enough to easily add new file formats when the need arises. |
---|
| 315 | To properly import data, extra information may have to be read from |
---|
| 316 | secondary calibration files (such as GTP, Gated Total Power, for 3~mm |
---|
| 317 | wavelength data taken with Mopra). The import functions should be |
---|
| 318 | flexible enough to gracefully handle data files with missing headers |
---|
| 319 | etc. They should also be able to make telescope and date specific |
---|
| 320 | corrections to the data (for ATNF observatories). |
---|
| 321 | |
---|
| 322 | The software must be able to read (import) the following file formats. |
---|
| 323 | |
---|
| 324 | \requirement{The rpfits file format produced by all current ATNF |
---|
| 325 | correlators.}{0} |
---|
| 326 | |
---|
| 327 | \requirement{SDFITS (currently written by {\tt SPC}).}{1} |
---|
| 328 | |
---|
| 329 | \requirement{Simple ``image'' FITS (used by CLASS}{2} |
---|
| 330 | |
---|
| 331 | \requirement{Historic ATNF single dish formats (Spectra, SPC, |
---|
| 332 | SLAP). Possibly a set of routines to translate these formats to SDFITs |
---|
| 333 | would suffice.}{3} |
---|
| 334 | |
---|
| 335 | \requirement{PSRFIT for pulsar spectroscopy.} |
---|
| 336 | |
---|
| 337 | \requirement{For online analysis, the software should be able to read |
---|
| 338 | an rpfits file which is is still currently open for writing by the |
---|
| 339 | telescope backend processor.}{1} |
---|
| 340 | |
---|
| 341 | \requirement{Data which has been observed in either a fixed frequency |
---|
| 342 | or Doppler tracked fashion needs to be handled transparently.}{1} |
---|
| 343 | |
---|
| 344 | The software should be able to export the data in the following formats. |
---|
| 345 | |
---|
| 346 | \requirement{Single Dish FITS.}{1} |
---|
| 347 | |
---|
| 348 | \requirement{Simple ``image'' FITS (used by CLASS. It must be possible |
---|
| 349 | to to export multiple spectra simultaneously, using default file name |
---|
| 350 | and postfix.}{2} |
---|
| 351 | |
---|
| 352 | \requirement{In a format which can be imported by other popular |
---|
| 353 | packages such as Class. }{2} |
---|
| 354 | |
---|
| 355 | \requirement{Simple ascii format, suitable for use with programs such |
---|
| 356 | as Perl, Python, SuperMongo etc.}{2} |
---|
| 357 | |
---|
| 358 | \requirement{The exported data should retain as much header data as |
---|
| 359 | possible. It should also be possible to request specific data be |
---|
| 360 | written in the desired form (B1950 coordinates, optical velocity |
---|
| 361 | definition etc).}{2} |
---|
| 362 | |
---|
| 363 | \requirement{The import function should apply relevant corrections |
---|
| 364 | (especially those which are time dependent) to specific |
---|
| 365 | telescopes. See $\S$\ref{sec:issues} for a list of currently known |
---|
| 366 | issues.}{1} |
---|
| 367 | |
---|
| 368 | \subsection{Sky subtraction} |
---|
| 369 | \label{sec:skysubtraction} |
---|
| 370 | To remove the effects of the passband filter shape and atmospheric |
---|
| 371 | fluctuations across the band, sky subtraction must be performed on the |
---|
| 372 | data. The software must be able to do sky subtraction using both |
---|
| 373 | position switching (quotient spectra) and frequency switching |
---|
| 374 | techniques. |
---|
| 375 | |
---|
| 376 | \requirement{\label{ref:skysub} Position switched sky subtraction |
---|
| 377 | should be implemented using the algorithm \medskip\reqeqn{T_{ref} |
---|
| 378 | \times \frac{S}{R} - T_{sig}} -- removes continuum\bigskip |
---|
| 379 | \reqeqn{T_{ref} \times \frac{S}{R} - T_{ref}} -- preserves |
---|
| 380 | continuum\medskip}{0} |
---|
| 381 | |
---|
| 382 | \requirement{The user should be able to specify an arbitrarily complex |
---|
| 383 | reference/source order (which repeats), which can then be used to make |
---|
| 384 | perform multiple sky subtractions in parallel.}{3} |
---|
| 385 | |
---|
| 386 | \requirement{Frequency switched sky subtraction should be |
---|
| 387 | supported. (Ref. Liszt, 1997, A\&AS, 124, 183) }{2} |
---|
| 388 | |
---|
| 389 | %\requirement{For wideband multibit sampled data it may be desirable or |
---|
| 390 | %even required to assume Tsys has a frequency dependency. Appropriate |
---|
| 391 | %sky subtraction algorithms will need to be investigated.}{3} |
---|
| 392 | |
---|
| 393 | \requirement{For pulsar binned data, the (user specified) off pulse |
---|
| 394 | bins can be used as the reference spectra. Due to potentially rapid |
---|
| 395 | amplitude fluctuations, sky subtractions may need to be done on a per |
---|
| 396 | integration basis.}{3} |
---|
| 397 | |
---|
| 398 | Multibeam systems can observe in a nodding fashion (called MX mode at |
---|
| 399 | Parkes), where the telescope position is nodded between scans so that |
---|
| 400 | the source is observed in turn by two beams and a reference spectra |
---|
| 401 | for one beam is obtained while the other is observing the target source. |
---|
| 402 | |
---|
| 403 | \requirement{For multibeam systems, it must be possible to perform sky |
---|
| 404 | subtraction with the source and reference in an alternate pair of |
---|
| 405 | beams}{2} |
---|
| 406 | |
---|
| 407 | \subsection{Baseline removal} |
---|
| 408 | |
---|
| 409 | Baseline removal is needed to correct for imperfections in sky |
---|
| 410 | subtraction. Depending on the stability of the system, the residual |
---|
| 411 | spectral baseline errors can be small or quite large. Baseline removal |
---|
| 412 | is usually done by fitting a function to the (user specified) line |
---|
| 413 | free channels. |
---|
| 414 | |
---|
| 415 | \requirement{The software must be able to do baseline removal by |
---|
| 416 | fitting a n'th order polynomials to the line free channels using a |
---|
| 417 | least squares method.}{0} |
---|
| 418 | |
---|
| 419 | %\requirement{The baseline fitting should be reversible, i.e. the fit |
---|
| 420 | %parameters must be retained.}{2} |
---|
| 421 | |
---|
| 422 | \requirement{Removal of standing wave ripples should be done by |
---|
| 423 | fitting a Sine function to the line free channels.}{2} |
---|
| 424 | |
---|
| 425 | \requirement{``Robust'' fitting functions should be available, which are more |
---|
| 426 | tolerant to RFI.}{1} |
---|
| 427 | |
---|
| 428 | \requirement{Automatic techniques for baselining should be |
---|
| 429 | investigated.}{3} |
---|
| 430 | |
---|
| 431 | \subsection{Line Profile Fitting} |
---|
| 432 | |
---|
| 433 | The user will want to fit multicomponent line profiles to the data in |
---|
| 434 | a simple manner and be able to manipulate the exact fitting |
---|
| 435 | parameters. |
---|
| 436 | |
---|
| 437 | \requirement{The software must be able to do multi-component Gaussian |
---|
| 438 | fitting of the spectra. The initial amplitude, width and velocity of |
---|
| 439 | each component should be able to be set by the user and specific |
---|
| 440 | values to be fit should be easily set.}{0} |
---|
| 441 | |
---|
| 442 | \requirement{The reduce Chi square (or similar statistic) of the fit |
---|
| 443 | should given to the user, so that they can easily see if adding extra |
---|
| 444 | components give a statistically significant improvement to the fit.}{1} |
---|
| 445 | |
---|
| 446 | %\requirement{The fit parameters should be stored with the data so that |
---|
| 447 | %the user can work on multiple data sets simultaneously and experiment |
---|
| 448 | %with different fitting values. These values should be saved to disk |
---|
| 449 | %along with the data.}{1} |
---|
| 450 | |
---|
| 451 | \requirement{For multiple polarisation data, the individual stokes |
---|
| 452 | parameters or polarisation products should be fit independently.}{1} |
---|
| 453 | |
---|
| 454 | \requirement{There should be an easy way of exporting the fit |
---|
| 455 | parameter from multiple spectra, e.g. as an ASCII table.}{2} |
---|
| 456 | |
---|
| 457 | \requirement{It should be also possible to do constrained fitting of |
---|
| 458 | multiple hyperfine components, e.g. the NH$_3$ hyperfine |
---|
| 459 | components. (The constraints may be either the frequency separation of |
---|
| 460 | the individual components or the amplitude ratio etc.)}{3} |
---|
| 461 | |
---|
| 462 | \requirement{It must be possible to alter the line profile fit |
---|
| 463 | parameter values by hand at any stage.}{2} |
---|
| 464 | |
---|
| 465 | \requirement{It must be possible to ``fix'' particular values of the |
---|
| 466 | line profile parameters, so that only subset of lines or (say) the |
---|
| 467 | width of a line is fit.}{1} |
---|
| 468 | |
---|
| 469 | \requirement{The software should allow hooks for line profile shapes |
---|
| 470 | other than Gaussian to be added in the future, possible user |
---|
| 471 | specified.}{2} |
---|
| 472 | |
---|
| 473 | %\makenote{Should it be possible to attach multiple sets of fits to the |
---|
| 474 | %data (similar to CL tables in classic AIPS), so the user can |
---|
| 475 | %experiment with different ways of fitting the data?} |
---|
| 476 | |
---|
| 477 | %\makenote{Should calculations of rotational temperatures etc be |
---|
| 478 | %handled when fitting hyperfine components, or should the user be doing |
---|
| 479 | %this themselves?} |
---|
| 480 | |
---|
| 481 | \subsection{Calibration} |
---|
| 482 | |
---|
| 483 | The software should handle all basic system temperature (Tsys) and |
---|
| 484 | gain calibration as well as opacity corrections where relevant. The |
---|
| 485 | Tsys value should be contained in the rpfits files. The actual |
---|
| 486 | application of the T$_{\mbox{sys}}$ factor will be applied as part of |
---|
| 487 | the sky subtraction ($\S$\ref{sec:skysubtraction}). The units of Tsys |
---|
| 488 | recorded in the data may be either in Jy or Kelvin, which will affect |
---|
| 489 | how the data is calibrated. The rpfits file does {\em not} distinguish |
---|
| 490 | if the flux units are Kelvin or Janskys. |
---|
| 491 | |
---|
| 492 | \requirement{Gain elevation corrections should be implemented using a |
---|
| 493 | elevation dependent polynomial. The polynomial coefficients will be |
---|
| 494 | telescope and frequency dependent. They will also have a (long term) |
---|
| 495 | time dependence.}{1} |
---|
| 496 | |
---|
| 497 | \requirement{The user may wish to supply their own gain polynomial.}{2} |
---|
| 498 | |
---|
| 499 | \requirement{When required by the user, the spectral units must be |
---|
| 500 | converted from Kelvin to Jansky. At higher (3mm) frequencies this |
---|
| 501 | conversion is often not applied. The conversion factor is\medskip |
---|
| 502 | \reqeqn{\mbox{Flux (Jy)} = \frac{T \times 2 k_b \times |
---|
| 503 | 10^{26}}{\eta A}},\medskip\\where $k_b$ is Boltzmann's constant, A is |
---|
| 504 | the illuminated area of the telescope and $\eta$ is the efficiency of |
---|
| 505 | the telescope (frequency, telescope and time dependent)}{1} |
---|
| 506 | %%TODO%% Use planks formula here? |
---|
| 507 | |
---|
| 508 | \requirement{In some cases the recorded Tsys values will be |
---|
| 509 | wrong. There needs to be a mechanism to scale the Tsys value and the |
---|
| 510 | spectrum if the Tsys value has already been applied (i.e. a simple and |
---|
| 511 | consistent rescaling factor).}{2} |
---|
| 512 | |
---|
| 513 | \requirement{The data may need to be corrected for opacity effects, |
---|
| 514 | particularly at frequencies of 20~GHz and higher. The opacity factor |
---|
| 515 | to apply is given by\medskip\reqeqn{C_o = e^{\tau/cos(z)}}\medskip\\ |
---|
| 516 | where $\tau$ is the opacity and z is the zenith angle (90-El). These |
---|
| 517 | corrections will generally be derived from periodic ``skydip'' |
---|
| 518 | measurements. These values will not be contained in the rpfits files, |
---|
| 519 | so there should be a simple way of the software obtaining them and |
---|
| 520 | interpolating in time (the user should not {\em have} to type them in, |
---|
| 521 | but may want to). Reading in an ascii file which contains the skydip |
---|
| 522 | data along with a time-stamp would be one possibility.}{1} |
---|
| 523 | |
---|
| 524 | \requirement{For wideband, multibit observations, the software should |
---|
| 525 | have the option to handle Tsys which varies across the band. The exact |
---|
| 526 | implementation will have to be decided once experience is gained with |
---|
| 527 | the new Mopra digital filterbank. This will affect the sky subtraction |
---|
| 528 | algorithms (requirement \reqref{ref:skysub}).}{2} |
---|
| 529 | |
---|
| 530 | %\makenote{Is the dependence of gain on frequency weak enough for one |
---|
| 531 | %set of coefficients for each receiver, or is a full frequency dependent |
---|
| 532 | %set of values needed?} |
---|
| 533 | |
---|
| 534 | %\makenote{Should it be possible to read ``correct'' Tsys values from |
---|
| 535 | %an external ascii file?} |
---|
| 536 | |
---|
| 537 | \subsection{Editing \& RFI robustness} |
---|
| 538 | |
---|
| 539 | In a data set with many observations, individual spectra may be |
---|
| 540 | corrupted or the data may be affected by RFI and ``birdies''. The user |
---|
| 541 | needs to be able to easily flag individual spectra or channels. This |
---|
| 542 | may affect other routines such as sky-subtraction, as this will |
---|
| 543 | disrupt the reference/source sequence. |
---|
| 544 | |
---|
| 545 | \requirement{The user must be able to set an entire spectra or part |
---|
| 546 | thereof (individual polarisation, IF etc) as being invalid. The |
---|
| 547 | effected channels should either be blanked or interpolated depending |
---|
| 548 | on the user wishes. When blanked data is plotted, the plotting routine |
---|
| 549 | should also either interpolate the data on the fly or show a blank in |
---|
| 550 | the spectrum, depending on the users preferences.}{1} |
---|
| 551 | |
---|
| 552 | \requirement{The user must be able to indicate an individual spectral |
---|
| 553 | point or range of spectral points are invalid. This should be applied |
---|
| 554 | to an individual spectra, or set of spectra.}{1} |
---|
| 555 | |
---|
| 556 | \requirement{The user should be able to plot the average spectral flux |
---|
| 557 | across the band, or part of the band, as a function of time and |
---|
| 558 | interactively select sections of data which should be marked as |
---|
| 559 | invalid (similar to IBLED in classic aips).}{3} |
---|
| 560 | |
---|
| 561 | \requirement{Where relevant, fitting routines etc should have the |
---|
| 562 | option of selecting RFI tolerant (``robust'') algorithms. This will |
---|
| 563 | require investigating alternate fitting routines other than the |
---|
| 564 | least-squares approach.}{3} |
---|
| 565 | |
---|
| 566 | \requirement{A routine to automatically find birdies or RFI corrupted |
---|
| 567 | data and indicate the data as invalid would be useful.}{3} |
---|
| 568 | |
---|
| 569 | \requirement{Other routines must be able to cope with portions of data |
---|
| 570 | which are marked as invalid.}{1} |
---|
| 571 | |
---|
| 572 | \subsection{Spectra mathematics and manipulation} |
---|
| 573 | |
---|
| 574 | A flexible suite of mathematical operations on the spectra should be |
---|
| 575 | possible. This should include options such as adding, subtracting, |
---|
| 576 | averaging and scaling the data. For common operations such as |
---|
| 577 | averaging and smoothing, it must be simple for the user to invoke the |
---|
| 578 | function (i.e. not to have to start up a complex spectral |
---|
| 579 | calculator). Where it makes sense, it should be possible to manipulate |
---|
| 580 | multiple spectra simultaneously. |
---|
| 581 | |
---|
| 582 | The spectral manipulations which should be available are: |
---|
| 583 | |
---|
| 584 | \requirement{Add or subtract multiple spectra.}{1} |
---|
| 585 | |
---|
| 586 | \requirement{Averaging multiple spectra, with optional weighting based |
---|
| 587 | on Tsys, integration or rms. If the velocity of the spectra to be |
---|
| 588 | averaged is different, the data should be automatically aligned in |
---|
| 589 | velocity.}{0} |
---|
| 590 | |
---|
| 591 | \requirement{Various robust averaging possibilities (e.g. median |
---|
| 592 | averaging, clipped means etc) should be possible.}{2} |
---|
| 593 | |
---|
| 594 | \requirement{Re-sampling or re-binning of the data to a lower (or |
---|
| 595 | higher) spectral resolution (i.e. change the number of spectral |
---|
| 596 | points). The re-sampling factor may not necessarily be an integer.}{2} |
---|
| 597 | |
---|
| 598 | \requirement{It must be possible to shift the data in |
---|
| 599 | ``frequency/velocity''. This should include channel, frequency and |
---|
| 600 | velocity shifts of an arbitrary amount.}{1} |
---|
| 601 | |
---|
| 602 | \requirement{Spectral smoothing of the data. Hanning, Tukey, boxcar |
---|
| 603 | and Gaussian smoothing of variable widths should be possible.}{1} |
---|
| 604 | |
---|
| 605 | \requirement{Scaling of the spectra.}{1} |
---|
| 606 | |
---|
| 607 | \requirement{Calculate basic statistical values (maximum, minimum, |
---|
| 608 | rms, mean) on a range of spectral points. The range may not be |
---|
| 609 | contiguous. The calculated rms value should be retained with the |
---|
| 610 | spectra so it can be optionally used for weighted averaging of |
---|
| 611 | spectra.}{1} |
---|
| 612 | |
---|
| 613 | \requirement{It must be possible to calculate the flux integral over a |
---|
| 614 | range of channels. The units should be Jy.km/s (or Kelvin.km/s). The |
---|
| 615 | channel range for the calculation should be specific via the GUI or |
---|
| 616 | CLI.}{2} |
---|
| 617 | |
---|
| 618 | \requirement{It must be possible to calculate the numerical ``width'' |
---|
| 619 | of a line (full width at half maximum type measurement). This should |
---|
| 620 | be calculated by specifying a channel range and finding the maximum |
---|
| 621 | value in this range and then finding the interpolated crossing point |
---|
| 622 | of the data as a user defined fraction of the maximum (default |
---|
| 623 | 50\%). The profile width and velocity mid-point should then be |
---|
| 624 | computed. If the profile shape is complex (e.g. double arch) with |
---|
| 625 | multiple crossing points of the fraction value, the minimum and |
---|
| 626 | maximum width values should be calculated. There should be the option |
---|
| 627 | of using a user specified ``maximum value''.}{2} |
---|
| 628 | |
---|
| 629 | \requirement{The user must be able to easily change the rest-frequency |
---|
| 630 | to which the velocity is referenced.}{1} |
---|
| 631 | |
---|
| 632 | \requirement{FFT filtering for high- and lowpass filtering and |
---|
| 633 | tapering.}{3} |
---|
| 634 | |
---|
| 635 | \requirement{It should be possible to FFT the data to and from power |
---|
| 636 | spectra to the autocorrelation function.}{2} |
---|
| 637 | |
---|
| 638 | \requirement{The user may wish to compute the cross correlation |
---|
| 639 | function of two spectra. The result should be a standard ``spectra'', |
---|
| 640 | which can be displayed and analysed using other functions (max, rms |
---|
| 641 | etc).}{3} |
---|
| 642 | |
---|
| 643 | \requirement{Complex experiment specific processing can often be done |
---|
| 644 | using a series of the simple of basic functions. A spectral calculator |
---|
| 645 | options should be added to the CLI to perform a series of |
---|
| 646 | manipulations on a set of spectra.}{3} |
---|
| 647 | |
---|
| 648 | The user may want to perform specific analysis on the data using the |
---|
| 649 | functionality above, but wish to do the manipulation between two |
---|
| 650 | polarisations or IFs. Allowing the functions to also, optionally, |
---|
| 651 | specify specific polarisations or IF would be an implementation and |
---|
| 652 | interface nightmare. The simplest solution is the allow the data to be |
---|
| 653 | ``split'' into separate spectra. |
---|
| 654 | |
---|
| 655 | \requirement{It must be possible to take multi IF, multibeam or |
---|
| 656 | polarisation data and split out the individual spectral portions to |
---|
| 657 | form self contained spectra.}{2} |
---|
| 658 | |
---|
| 659 | \subsection{Polarimetry} |
---|
| 660 | |
---|
| 661 | The software must fully support polarmetric analysis. This includes |
---|
| 662 | calibration and basic conversions. Observations may be made with |
---|
| 663 | linear or circular feed and the backend may or may not compute the |
---|
| 664 | cross polarisation products. As such the software must cope with a |
---|
| 665 | variety of conversions. The software should be able to calculate |
---|
| 666 | stokes parameters with or without solving for leakage terms. |
---|
| 667 | |
---|
| 668 | %\makenote{It is debatable whether stokes I is the sum or average or |
---|
| 669 | %two dual polarisation measurements.} |
---|
| 670 | |
---|
| 671 | \requirement{All functions on the data (calibration, sky subtraction |
---|
| 672 | spectral mathematics) must support arbitrary, multiple, polarisation |
---|
| 673 | (linear, circular \& stokes and single, dual \& cross |
---|
| 674 | polarisations.}{1} |
---|
| 675 | |
---|
| 676 | \requirement{It must be possible to calculate stokes I from single or |
---|
| 677 | dual polarisation observations.}{1} |
---|
| 678 | |
---|
| 679 | \requirement{Average a mixture of dual polarisation and single |
---|
| 680 | polarisation data and form average stokes I (e.g. for a long |
---|
| 681 | observation of a source, in which one polarisation is missing for some |
---|
| 682 | time.}{3} |
---|
| 683 | |
---|
| 684 | \requirement{Full stokes parameters should be obtained from dual pol |
---|
| 685 | (linear or circular) observations where the cross polarisation |
---|
| 686 | products have been calculated.}{1} |
---|
| 687 | |
---|
| 688 | %\requirement{If the observations used linear polarisations and the |
---|
| 689 | %cross polarisations were not computed, the source needs to be |
---|
| 690 | %observed with the feeds set at least 3 different parallactic angles |
---|
| 691 | %(note that if dual linear feeds are available, 2 orthogonal |
---|
| 692 | %parallactic angles are obtained at once). The Stokes parameters can be |
---|
| 693 | %solved using a least squares fit to the equation: |
---|
| 694 | %\reqeqn{Iu/2 + Ip * cos^2 (PA + p)},\\ |
---|
| 695 | %where PA is the linear feed position angle, p is the polarisation |
---|
| 696 | %angle, Iu and Ip and the unpolarised and linearly polarised |
---|
| 697 | %intensity. {\em Stolen from SPC. I need to write this in more useful |
---|
| 698 | %language. Is this technique likely to be used anymore?.}}{3} |
---|
| 699 | |
---|
| 700 | \requirement{If dual circular polarisation measurements are taken, |
---|
| 701 | without computing the cross products, the software should still be |
---|
| 702 | able to compute stokes I and V.}{2} |
---|
| 703 | |
---|
| 704 | \requirement{The software should be able to calculate leakage terms |
---|
| 705 | from a calibrator source and correct the data either before or after |
---|
| 706 | conversion to Stokes. (ref. Johnston, 2002, PASA, 19, 277)}{3} |
---|
| 707 | |
---|
| 708 | \requirement{The software should be able to determine absolute |
---|
| 709 | position angle from a calibrator source and correct the data either |
---|
| 710 | before or after conversion to Stokes.}{3} |
---|
| 711 | |
---|
| 712 | \requirement{Zeeman splitting factors should be derived from |
---|
| 713 | (previous) profile fitting and the left and right circular |
---|
| 714 | polarisations. The velocity shift varies linearly with the magnetic |
---|
| 715 | field, but the scaling factor depends on the molecule and |
---|
| 716 | transition. Scaling factor for common transitions should be known by |
---|
| 717 | the software and the user able to enter factors for less common |
---|
| 718 | transitions. Correctly identifying Zeeman pairs is crucial in getting |
---|
| 719 | the correct result. The software should attempt to make an initial |
---|
| 720 | guess of pairs (based on component velocity and width) but make the |
---|
| 721 | user confirm and override the pairing if required.}{3} |
---|
| 722 | |
---|
| 723 | \subsection{Data Selection} |
---|
| 724 | While the software is running the user will usually have loaded |
---|
| 725 | multiple (possibly many) spectra each of which may have multiple IFs, |
---|
| 726 | data from multiple beams and multiple polarisations. The user will |
---|
| 727 | want to be able to quickly flip from considering one spectra to |
---|
| 728 | another and, where relevant, want to perform parallel processing on |
---|
| 729 | multiple spectra at once (e.g. baselining a sequence of on/off |
---|
| 730 | observations of the same source which will later be averaged |
---|
| 731 | together). |
---|
| 732 | |
---|
| 733 | \requirement{The software needs an easy-to-use mechanism to select |
---|
| 734 | either individual or multiple spectra for viewing, parallel processing |
---|
| 735 | etc.}{1} |
---|
| 736 | |
---|
| 737 | \requirement{An easy-to-use mechanism to select individual IFs, beams |
---|
| 738 | or polarisations is needed.}{1} |
---|
| 739 | |
---|
| 740 | \requirement{\label{ref:chansel} The range of spectral points to use |
---|
| 741 | for baseline removal, statistical calculations, RFI editing, analysis |
---|
| 742 | etc must be easily set by the user from both the CLI and GUI. From the |
---|
| 743 | CLI there must be the option of setting the range using a variety of |
---|
| 744 | units (channel number, velocity, frequency). The selection range will |
---|
| 745 | probably not be a contiguous set of channels, but many sets of |
---|
| 746 | disjoint channel ranges. For some tasks (such as baseline subtraction |
---|
| 747 | and statistical values), the channel range should be retained and be |
---|
| 748 | available as a plot overlay.}{1} |
---|
| 749 | |
---|
| 750 | \requirement{When performing baseline subtraction on many spectra |
---|
| 751 | simultaneously, the software should have a mechanism for identifying |
---|
| 752 | ``on'' and ``off'' spectra and automatically selecting the signal and |
---|
| 753 | quotient spectra. The algorithm needs to cope with on/off/on/off |
---|
| 754 | sequences as well as off/on/on/off. If an individual quotient spectra |
---|
| 755 | has been marked as invalid, an alternative should be found.}{3} |
---|
| 756 | |
---|
| 757 | \requirement{The software should be able to select sets of sources |
---|
| 758 | based on simple regular expression type filtering (wild cards) on a |
---|
| 759 | range of header values. Examples include G309$*$ or G309$*$w to select |
---|
| 760 | on source name, or NH3$*$ to select on molecule name.}{3} |
---|
| 761 | |
---|
| 762 | \subsection{Plugins} |
---|
| 763 | |
---|
| 764 | \requirement{It would be desirable to support ``plugins'', user |
---|
| 765 | definable functions for specific processing. The plugin code must have |
---|
| 766 | full access (read/write) to the spectra data and headers. It should |
---|
| 767 | also be possible to create new spectra which the software treats the |
---|
| 768 | same as the original data. Preferably some (limited) access to the |
---|
| 769 | plotter would also be possible and a number of the standard functions |
---|
| 770 | accessible as ``library'' routines.}{3} |
---|
| 771 | |
---|
| 772 | \subsection{Pipelining} |
---|
| 773 | |
---|
| 774 | \requirement{Some sort of pipelining mode is required. This would |
---|
| 775 | involve doing a quotient spectra, applying appropriate calibration and |
---|
| 776 | possibly fitting a Gaussian to any lines present.}{3} |
---|
| 777 | |
---|
| 778 | \subsection{Methanol Multibeam Survey} |
---|
| 779 | |
---|
| 780 | The software may need to support reduction of data from the methanol |
---|
| 781 | multibeam project. If so the pipelining will need to be flexible and |
---|
| 782 | powerful enough to support this. |
---|
| 783 | |
---|
| 784 | \subsection{Miscellaneous functionality} |
---|
| 785 | |
---|
| 786 | \requirement{The software should be able to take a simple ``grid'' of |
---|
| 787 | observations (normally a set of observations in a cross pattern on the |
---|
| 788 | sky) and, for a subset of channels, fit the position of the |
---|
| 789 | emission. The fit positions should be either plotted on the screen or |
---|
| 790 | exported in a simple ascii form.}{3} |
---|
| 791 | |
---|
| 792 | \requirement{The kinematic distance of a source should be calculated |
---|
| 793 | using basic Galactic rotation models. Multiple Galactic rotation |
---|
| 794 | models must be supported and a mechanism for easily adding more.}{3} |
---|
| 795 | |
---|
| 796 | \requirement{For 1420 MHz observations of HI, the rms (Tsys) values |
---|
| 797 | vary significantly across the band. The software should be able to |
---|
| 798 | compute the rms as a function of frequency across the spectra from the |
---|
| 799 | off-pulse data and then be able to plot n-sigma error bars on the |
---|
| 800 | spectra.}{3} |
---|
| 801 | |
---|
| 802 | \requirement{It should be possible to take a selection of calibrated |
---|
| 803 | spectra which are then passed to the ``Gridzilla'' program to produce |
---|
| 804 | an image cube. Analysis of this cube would be done using external |
---|
| 805 | programs (e.g. Miriad, aips++)}{3} |
---|
| 806 | |
---|
| 807 | \section{Help} |
---|
| 808 | |
---|
| 809 | \requirement{There should be built-in web-based documentation, which |
---|
| 810 | can be easily kept up-to-date}{1} |
---|
| 811 | |
---|
| 812 | \requirement{A short and simple end-to-end cookbook for basic data |
---|
| 813 | analysis should be available.}{1} |
---|
| 814 | |
---|
| 815 | \section{Data and meta-data} |
---|
| 816 | |
---|
| 817 | \requirement{The software must be capable of handling multi-IF |
---|
| 818 | (potentially dozens of IFs) and multi-beam data with arbitrary |
---|
| 819 | polarisation (e.g. single pol, dual pol, full stokes etc).}{1} |
---|
| 820 | |
---|
| 821 | \requirement{The software should handle pulsar binned data for pulsar |
---|
| 822 | absorption experiments.}{3} |
---|
| 823 | |
---|
| 824 | \subsection{History} |
---|
| 825 | |
---|
| 826 | \requirement{A user viewable history of data processing steps should |
---|
| 827 | be kept as part of the data. Where possible this should be retained |
---|
| 828 | when data is imported from other packages.}{1} |
---|
| 829 | |
---|
| 830 | \requirement{It should be possible to use the history information to |
---|
| 831 | create template pipeline scripts for batch processing.}{2} |
---|
| 832 | |
---|
| 833 | \subsection{Multiple IFs} |
---|
| 834 | |
---|
| 835 | \requirement{If multiple IFs are present (currently Tidbinbilla can |
---|
| 836 | produce two IFs and the new wideband spectrometer for Mopra may have |
---|
| 837 | dozens of IFs), the software should handle the data |
---|
| 838 | transparently. Potentially each IF may have a significantly different |
---|
| 839 | sky frequency and be observing a different molecule or transition with |
---|
| 840 | a different rest frequency. From the users point of view, |
---|
| 841 | simultaneously obtained IFs should be kept within the same |
---|
| 842 | ``container'' (not split into a myriad of separate ``container'').}{1} |
---|
| 843 | |
---|
| 844 | %\makenote{Does the case of multiple lines (so multiple |
---|
| 845 | %rest frequencies) within a single IF need special attention?} |
---|
| 846 | |
---|
| 847 | \subsection{Multibeam} |
---|
| 848 | |
---|
| 849 | \requirement{Basic handling of multibeam data should be possible (ie |
---|
| 850 | in general each beam will be treated as a separate observation, but |
---|
| 851 | all within the same container. The user should be able to view or |
---|
| 852 | process either individual beams or all beams in parallel.}{2} |
---|
| 853 | |
---|
| 854 | \requirement{The use of a single beam observing a source and the |
---|
| 855 | rest of the beams as reference beams for sky-subtraction should be |
---|
| 856 | investigated.}{2} |
---|
| 857 | |
---|
| 858 | \subsection{Robust fitting} |
---|
| 859 | |
---|
| 860 | \requirement{If robust fitting using median filtering is used, then |
---|
| 861 | the individual integrations from the observations should {\em not} be |
---|
| 862 | averaged when the data is imported, but retained within a single |
---|
| 863 | container. Inspection of this data should be optionally of the averaged |
---|
| 864 | or individual data.}{2} |
---|
| 865 | |
---|
| 866 | \subsection{Fit parameters} |
---|
| 867 | |
---|
| 868 | \requirement{The fitting parameters for functions which have been fit |
---|
| 869 | to the data (e.g. for baseline removal or Gaussian fits) should be |
---|
| 870 | retained as an integral part of the data and stored permantely on |
---|
| 871 | disk.}{1} |
---|
| 872 | |
---|
| 873 | \requirement{It must be possible to export fitting values in an |
---|
| 874 | appropriate form. (i.e. ascii text format)}{1} |
---|
| 875 | |
---|
| 876 | \requirement{It should be possible to ``undo'' functions which have |
---|
| 877 | been subtracted from the data (e.g. baseline polynomials).}{3} |
---|
| 878 | |
---|
| 879 | \subsection{Coordinate frames and units} |
---|
| 880 | |
---|
| 881 | \requirement{Coordinate frames and unit selection and handling needs |
---|
| 882 | to be flexible and relatively transparent to the user (i.e. if the |
---|
| 883 | users preference is for LSRK velocities, they do not need to worry |
---|
| 884 | about the reference frame in which the data was observed).}{1} |
---|
| 885 | |
---|
| 886 | \requirement{At a minimum the following reference frames and |
---|
| 887 | conventions should be handled: \setlength{\parindent}{0pt} |
---|
| 888 | |
---|
| 889 | \smallskip |
---|
| 890 | \anitem{Position}{(RA,Dec) in J2000 \& B1950 (as well as other |
---|
| 891 | arbitrary epochs), Galactic, (Az,El).} |
---|
| 892 | |
---|
| 893 | \anitem{Frequency}{Velocity (Topocentric, Geocentric, Barycentric, |
---|
| 894 | Heliocentric, kinematical LSR, dynamical LSR, Rest), Frequency |
---|
| 895 | (MHz, GHz), channel number.} |
---|
| 896 | |
---|
| 897 | \anitem{Velocity}{ Optical, Radio, Relativistic.} |
---|
| 898 | |
---|
| 899 | \anitem{Flux}{ Jansky, Kelvin (mJy etc).}}{1} |
---|
| 900 | |
---|
| 901 | \requirement{All data should be internally labelled with the |
---|
| 902 | appropriate coordinate frame and units. If this information is |
---|
| 903 | ambiguous for some reason, it should be set when the data is imported |
---|
| 904 | and the user should not have to worry about it again.}{1} |
---|
| 905 | |
---|
| 906 | \requirement{It should be clear to the user what coordinate frame |
---|
| 907 | (velocity, position etc) the data is being presented as.}{1} |
---|
| 908 | |
---|
| 909 | \subsection{Meta-data} |
---|
| 910 | |
---|
| 911 | A comprehensive set of header data should be read from the input data |
---|
| 912 | files. In general all meta-data available in the rpfits file should be |
---|
| 913 | retained. The user may wish to enter some specific values by hand. |
---|
| 914 | |
---|
| 915 | \requirement{All header data should be viewable and editable by the |
---|
| 916 | user. This includes changes such as scaling the given Tsys values.}{2} |
---|
| 917 | |
---|
| 918 | \requirement{Missing header data should be handled gracefully, |
---|
| 919 | i.e. the software should fill the values with ``blanks'' and be able |
---|
| 920 | to continue to process the data if possible.}{1} |
---|
| 921 | |
---|
| 922 | \requirement{The user must be able to add missing header data, which |
---|
| 923 | is not present in the RPFITs file. It must be possible to add the same |
---|
| 924 | header data to multiple scans simultaneously.}{2} |
---|
| 925 | |
---|
| 926 | \extendedrequirement{ |
---|
| 927 | The following header data would be required per scan: |
---|
| 928 | \begin{itemize} |
---|
| 929 | \item Source name |
---|
| 930 | \item Scan type (signal or reference) |
---|
| 931 | \item Integration time |
---|
| 932 | \item Scan length (actual time of observation, $\ge$ integration time) |
---|
| 933 | \item Telescope |
---|
| 934 | \item UT time and date of observation |
---|
| 935 | \item Telescope elevation of observation |
---|
| 936 | \item Parallactic angle |
---|
| 937 | \item Beam size |
---|
| 938 | \item Scan ID |
---|
| 939 | \item Observer |
---|
| 940 | \item Project |
---|
| 941 | \item Polarisation |
---|
| 942 | \item Receiver |
---|
| 943 | \item Telescope coordinates |
---|
| 944 | \item Weather info (temperature, pressure, humidity) |
---|
| 945 | \item LO chain setup |
---|
| 946 | \item User axis display preference (LSR velocity, frequency etc). |
---|
| 947 | \end{itemize} |
---|
| 948 | }{1} |
---|
| 949 | |
---|
| 950 | \extendedrequirement{ |
---|
| 951 | \label{req:if} |
---|
| 952 | The following header data is required for each IF, beam etc: |
---|
| 953 | \begin{itemize} |
---|
| 954 | \item Source coordinates and coordinate frame |
---|
| 955 | \item Frequency/velocity axis definition and type |
---|
| 956 | \item System Temperature |
---|
| 957 | \item Antenna gain (if Tsys measured in Kelvin) |
---|
| 958 | \item Beam number |
---|
| 959 | \item Molecule rest frequency$^\dagger$ |
---|
| 960 | \item Molecular name$^\dagger$ |
---|
| 961 | \item Molecular transition$^\dagger$ |
---|
| 962 | \item Molecular formula$^\dagger$ |
---|
| 963 | \end{itemize} |
---|
| 964 | }{1} |
---|
| 965 | |
---|
| 966 | \requirement{The molecular formula could be stored with embedded |
---|
| 967 | superscripted and subscripted symbols for ``pretty'' printing on the |
---|
| 968 | plotted, but printed in plain text on the CLI or in ascii output}{3} |
---|
| 969 | |
---|
| 970 | Some molecular line rest-frequencies are close enough that two or more |
---|
| 971 | molecules or transitions may be observed in a single IF. Typical |
---|
| 972 | examples include the 1665/1667~MHz OH maser pair, NH$_3$ transitions, |
---|
| 973 | and many observations in the 3~mm band. |
---|
| 974 | |
---|
| 975 | \vspace{\parskip} |
---|
| 976 | \requirement{The software should optionally support multiple lines per |
---|
| 977 | IF, by storing a set of rest frequencies per IF, rather than a single |
---|
| 978 | value. The header values in requirement \reqref{req:if} marked with a |
---|
| 979 | $\dagger$ would all have to be stored as an array of values rather |
---|
| 980 | than a scalar. A simple mechanism must be posible to change the |
---|
| 981 | currently ``active'' rest-frequency.}{3} |
---|
| 982 | |
---|
| 983 | \section{Installation} |
---|
| 984 | |
---|
| 985 | \requirement{It must be possible for astronomers to install the |
---|
| 986 | software at their own institute with either a moderate amount of OS |
---|
| 987 | experience or some help from the local system administrators. This |
---|
| 988 | includes installation on a central ``NFS'' server as well as local |
---|
| 989 | desk-tops.}{1} |
---|
| 990 | |
---|
| 991 | \requirement{The software must run on Solaris and all major flavours |
---|
| 992 | of Linux (Fedora/Redhat, Debian, etc). |
---|
| 993 | }{1} |
---|
| 994 | |
---|
| 995 | \requirement{It must be possible for users to |
---|
| 996 | install the software on their (unix) laptops and run with no network |
---|
| 997 | connection. }{1} |
---|
| 998 | |
---|
| 999 | \requirement{It should be relatively easy to upgrade to the lastest |
---|
| 1000 | version of the software.}{2} |
---|
| 1001 | |
---|
| 1002 | \requirement{The software should run on MacOS/X}{3} |
---|
| 1003 | |
---|
| 1004 | \requirement{It would be desirable for the software to run on |
---|
| 1005 | Windows.}{3} |
---|
| 1006 | |
---|
| 1007 | \section{Known Issues} |
---|
| 1008 | \label{sec:issues} |
---|
| 1009 | The following issue are known problems with the data from ATNF |
---|
| 1010 | telescopes, which probably should be automatically corrected for if at |
---|
| 1011 | all possible. The best place to do this is while loading the data. |
---|
| 1012 | |
---|
| 1013 | \subsection{General} |
---|
| 1014 | |
---|
| 1015 | \begin{itemize} |
---|
| 1016 | \item All polarisations in the RPFITS files are labelled as |
---|
| 1017 | XX/YY. These need to be relabelled as LL/RR when appropriate. |
---|
| 1018 | \end{itemize} |
---|
| 1019 | |
---|
| 1020 | \subsection{Mopra} |
---|
| 1021 | |
---|
| 1022 | \begin{itemize} |
---|
| 1023 | \item Data obtained in 2002 \& 2003 (and probably before) have an |
---|
| 1024 | error in the frequency headers (this may be corrected by an external |
---|
| 1025 | program). \makenote{Nedd Ladd} |
---|
| 1026 | |
---|
| 1027 | \item The (RA,Dec) positions in the data file are in date coordinates |
---|
| 1028 | not J2000. This causes problems for packages like Class when |
---|
| 1029 | averaging the data. \makenote{Maria Hunt} |
---|
| 1030 | |
---|
| 1031 | \item It is possible Tsys calibration is inconsistent currently. |
---|
| 1032 | \makenote{Cormac Purcell??} |
---|
| 1033 | |
---|
| 1034 | \end{itemize} |
---|
| 1035 | |
---|
| 1036 | \subsection{Parkes} |
---|
| 1037 | |
---|
| 1038 | \begin{itemize} |
---|
| 1039 | \item For pulsar data the automatic gain control is disabled. This |
---|
| 1040 | means the nominal Tsys measurement does not change and Tsys per |
---|
| 1041 | integration is encoded in a non-standard way. \makenote{Simon |
---|
| 1042 | Johnston} |
---|
| 1043 | \end{itemize} |
---|
| 1044 | |
---|
| 1045 | \subsection{Tidbinbilla} |
---|
| 1046 | |
---|
| 1047 | \begin{itemize} |
---|
| 1048 | \item All 20-GHz data is calibrated in flux units of Kelvin. |
---|
| 1049 | \end{itemize} |
---|
| 1050 | |
---|
| 1051 | \section{Acknowledgements} |
---|
| 1052 | |
---|
| 1053 | We would like to thank the following people for input directly or from |
---|
| 1054 | previous documents: Maria Hunt, Paul Jones, Jim Caswell \& Dave |
---|
| 1055 | McConnell, Frank Briggs, Juergen Ott, Daniel Pisano, Jim Lovell, Ray |
---|
| 1056 | Norris, WIm Brouw, Maxim Voronkov, Vincent McIntyre, Jessica Chapman, |
---|
| 1057 | Simon Johnston, Nedd Ladd, Lister Staveley-Smith, Cormac Purcell \& |
---|
| 1058 | Rachel Deacon. |
---|
| 1059 | |
---|
| 1060 | \end{document} |
---|