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