source: tags/release-1.1.5/docs/outputs.tex @ 1441

Last change on this file since 1441 was 447, checked in by MatthewWhiting, 16 years ago

Completing documentation, and incrementing version number ready for next release.

File size: 20.5 KB
Line 
1% -----------------------------------------------------------------------
2% outputs.tex: Section detailing the different forms of text- and
3%              plot-based output.
4% -----------------------------------------------------------------------
5% Copyright (C) 2006, Matthew Whiting, ATNF
6%
7% This program is free software; you can redistribute it and/or modify it
8% under the terms of the GNU General Public License as published by the
9% Free Software Foundation; either version 2 of the License, or (at your
10% option) any later version.
11%
12% Duchamp is distributed in the hope that it will be useful, but WITHOUT
13% ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
14% FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
15% for more details.
16%
17% You should have received a copy of the GNU General Public License
18% along with Duchamp; if not, write to the Free Software Foundation,
19% Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
20%
21% Correspondence concerning Duchamp may be directed to:
22%    Internet email: Matthew.Whiting [at] atnf.csiro.au
23%    Postal address: Dr. Matthew Whiting
24%                    Australia Telescope National Facility, CSIRO
25%                    PO Box 76
26%                    Epping NSW 1710
27%                    AUSTRALIA
28% -----------------------------------------------------------------------
29\secA{Outputs}
30\label{sec-output}
31
32\secB{During execution}
33
34\duchamp provides the user with feedback whilst it is running, to
35keep the user informed on the progress of the analysis. Most of this
36consists of self-explanatory messages about the particular stage the
37program is up to. The relevant parameters are printed to the screen at
38the start (once the file has been successfully read in), so the user
39is able to make a quick check that the setup is correct (see
40Appendix~{app-input} for an example).
41
42If the cube is being trimmed (\S\ref{sec-modify}), the resulting
43dimensions are printed to indicate how much has been trimmed. If a
44reconstruction is being done, a continually updating message shows
45either the current iteration and scale, compared to the maximum scale
46(when \texttt{reconDim = 3}), or a progress bar showing the amount of
47the cube that has been reconstructed (for smaller values of
48\texttt{reconDim}).
49
50During the searching algorithms, the progress through the search is
51shown. When completed, the number of objects found is reported (this
52is the total number found, before any merging is done).
53
54In the merging process (where multiple detections of the same object
55are combined -- see \S\ref{sec-merger}), two stages of output
56occur. The first is when each object in the list is compared with all
57others. The output shows two numbers: the first being how far through
58the list the current object is, and the second being the length of the
59list. As the algorithm proceeds, the first number should increase and
60the second should decrease (as objects are combined). When the numbers
61meet, the whole list has been compared. If the objects are being
62grown, a similar output is shown, indicating the progress through the
63list. In the rejection stage, in which objects not meeting the minimum
64pixels/channels requirements are removed, the total number of objects
65remaining in the list is shown, which should steadily decrease with
66each rejection until all have been examined. Note that these steps can
67be very quick for small numbers of detections.
68
69Since this continual printing to screen has some overhead of time and
70CPU involved, the user can elect to not print this information by
71setting the parameter \texttt{verbose = false}. In this case, the user
72is still informed as to the steps being undertaken, but the details of
73the progress are not shown.
74
75There may also be Warning or Error messages printed to screen. The
76Warning messages occur when something happens that is unexpected (for
77instance, a desired keyword is not present in the FITS header), but
78not detrimental to the execution. An Error message is something more
79serious, and indicates some part of the program was not able to
80complete its task. The message will also indicate which function or
81subroutine generated it -- this is primarily a tool for debugging, but
82can be useful in determining what went wrong.
83
84\secB{Text-based output files}
85
86\secC{Table of results}
87\label{sec-results}
88
89Finally, we get to the results -- the reason for running \duchamp in
90the first place. Once the detection list is finalised, it is sorted by
91the mean velocity of the detections (or, if there is no good WCS
92associated with the cube, by the mean $z$-pixel position). The results
93are then printed to the screen and to the output file, given by the
94\texttt{OutFile} parameter.
95
96The output consists of two sections. First, a list of the parameters
97are printed to the output file, for future reference. Next, the
98detection threshold that was used is given, so comparison can be made
99with other searches. The statistics estimating the noise parameters
100are given (see \S\ref{sec-stats}). Thirdly, the number of detections
101are reported.
102
103All this information, known as the ``header'', can either be written
104to the start of the output file (denoted by the parameter
105\texttt{OutFile}), or written to a separate file from the list of
106detections. This second option is activated by the parameter
107\texttt{flagSeparateHeader}, and the information is written to the
108file given by \texttt{HeaderFile}.
109
110The most interesting part, however, is the list of detected
111objects. This list, an example of which can be seen in
112Appendix~\ref{app-output}, contains the following columns (note that
113the title of the columns depending on WCS information will depend on
114the details of the WCS projection: they are shown below for the
115Equatorial and Galactic projection cases).
116
117\begin{Lentry}
118\item[{Obj\#}] The ID number of the detection (simply the
119  sequential count for the list, which is ordered by increasing
120  velocity, or channel number, if the WCS is not good enough to find
121  the velocity).
122\item[{Name}] The ``IAU''-format name of the detection (derived from the
123  WCS position -- see below for a description of the format).
124\item[{X,Y,Z}] The ``centre'' pixel position, determined by the input
125  parameter \texttt{pixelCentre}.
126\item[{RA/GLON}] The Right Ascension or Galactic Longitude of the centre
127  of the object.
128\item[{DEC/GLAT}] The Declination or Galactic Latitude of the centre of
129  the object.
130\item[{VEL}] The mean velocity of the object [units given by the
131  \texttt{spectralUnits} parameter].
132\item[{w\_RA/w\_GLON}] The width of the object in Right Ascension or
133  Galactic Longitude (depending on FITS coordinates) [arcmin].
134\item[{w\_DEC/w\_GLAT}] The width of the object in Declination Galactic
135  Latitude [arcmin].
136\item[{w\_VEL}] The full velocity width of the detection (max channel
137  $-$ min channel, in velocity units [see note below]).
138\item[{F\_int}] The integrated flux over the object, in the units of
139  flux times velocity, corrected for the beam if necessary.
140\item[{F\_tot}] The sum of the flux values of all detected voxels.
141\item[{F\_peak}] The peak flux over the object, in the units of flux.
142\item[{S/Nmax}] The signal-to-noise ratio at the peak pixel.
143\item[{X1, X2}] The minimum and maximum X-pixel coordinates.
144\item[{Y1, Y2}] The minimum and maximum Y-pixel coordinates.
145\item[{Z1, Z2}] The minimum and maximum Z-pixel coordinates.
146\item[{Npix}] The number of voxels (\ie distinct $(x,y,z)$ coordinates)
147  in the detection.
148\item[{Flag}] Whether the detection has any warning flags (see below).
149\end{Lentry}
150
151The user can specify the precision used to display the flux, velocity
152and S/Nmax values, by using the input parameters \texttt{precFlux},
153\texttt{precVel} and \texttt{precSNR} respectively. These values apply
154to the tables written to the screen and to the output file, as well as
155for the VOTable (see below).
156
157Note that the \texttt{X, Y, Z} columns depend on the \texttt{pixelCentre}
158parameter. This is because there are three alternative ways of
159expressing the centre of a detection, which are all listed in the list
160of detections written to the output file. These alternatives are:
161\begin{Lentry}
162\item[{X\_av, Y\_av, Z\_av}] The average pixel value in each
163  axis direction \ie X\_av is the average of the $x$-values of all
164  pixels in the detection.
165\item[{X\_cent, Y\_cent, Z\_cent}] The centroid position, being
166  the flux-weighted average of the pixels.
167\item[{X\_peak, Y\_peak, Z\_peak}] The location of the pixel
168  containing the peak flux value.
169\end{Lentry}
170These are also written to the table in the output file, although not
171to the screen (as it would make the width of the table
172unwieldy). Similarly, the \texttt{F\_tot} column is only written to the output
173file, and not at run-time.
174
175The \texttt{Name} is derived from the WCS position. For instance, a
176source that is centred on the RA,Dec position 12$^h$53$^m$45$^s$,
177-36$^\circ$24$'$12$''$ will be given the name J125345$-$362412, if the
178epoch is J2000, or the name B125345$-$362412 if it is B1950. An
179alternative form is used for Galactic coordinates: a source centred on
180the position ($l$,$b$) = (323.1245, 5.4567) will be called
181G323.124$+$05.457. If the WCS is not valid (\ie is not present or does
182not have all the necessary information), the \texttt{Name, RA, DEC,
183VEL} and related columns are not printed, but the pixel coordinates
184are still provided.
185
186The velocity units can be specified by the user, using the parameter
187\texttt{spectralUnits} (enter it as a single string with no
188spaces). The default value is km/s, which should be suitable for most
189users. These units are also used to give the units of integrated
190flux. Note that if there is no rest frequency specified in the FITS
191header, the \duchamp output will instead default to using Frequency,
192with units of MHz.
193
194If the WCS is absent or not sufficiently specified, then all columns
195from \texttt{RA/GLON} to \texttt{w\_VEL} will be left blank. Also,
196\texttt{F\_int} will be replaced with the more simple \texttt{F\_tot}.
197
198The \texttt{Flag} column contains any warning flags, such as:
199\begin{itemize}
200\item \textbf{E} -- The detection is next to the spatial edge of the image,
201meaning either the limit of the pixels, or the limit of the non-BLANK
202pixel region.
203\item \textbf{S} -- The detection lies at the edge of the spectral region.
204\item \textbf{N} -- The total flux, summed over all the (non-BLANK)
205pixels in the smallest box that completely encloses the detection, is
206negative. Note that this sum is likely to include non-detected
207pixels. It is of use in pointing out detections that lie next to
208strongly negative pixels, such as might arise due to interference --
209the detected pixels might then also be due to the interference, so
210caution is advised.
211\end{itemize}
212
213\secC{Other results lists}
214
215Three additional results files can also be requested. One option is a
216VOTable-format XML file, containing just the RA, Dec, Velocity and the
217corresponding widths of the detections, as well as the fluxes. The
218user should set \texttt{flagVOT = true}, and put the desired filename
219in the parameter \texttt{votFile} -- note that the default is for it
220not to be produced. This file should be compatible with all Virtual
221Observatory tools (such as Aladin%
222\footnote{%Aladin can be found on the web at
223\href{http://aladin.u-strasbg.fr/}{http://aladin.u-strasbg.fr/}}
224or TOPCAT\footnote{%Tool for OPerations on Catalogues And Tables:
225\href{http://www.star.bristol.ac.uk/~mbt/topcat/}%
226{http://www.star.bristol.ac.uk/~mbt/topcat/}}).
227
228A second option is an annotation file for use with the Karma toolkit
229of visualisation tools (in particular, with \texttt{kvis}). There are
230two options on how objects are represented, governed by the
231\texttt{annotationType} parameter. Setting this to \texttt{borders}
232results in a border being drawn around the spatial pixels of the
233object, in a manner similar to that seen in Fig.~\ref{fig-spect}. Note
234that Karma/\texttt{kvis} does not always do this perfectly, so the
235lines may not be directly lined up with pixel borders. The other
236option is \texttt{annotationType = circles}. This will draw a circle
237at the position of each detection, scaled by the spatial size of the
238detection, and number it according to the Obj\# given above. To make
239use of this option, the user should set \texttt{flagKarma = true}, and
240put the desired filename in the parameter \texttt{karmaFile} -- again,
241the default is for it not to be produced.
242
243The final optional results file produced is a simple text file that
244contains the spectra for each detected object. The format of the file
245is as follows: the first column has the spectral coordinate, over the
246full range of values; the remaining columns represent the flux values
247for each object at the corresponding spectral position. The flux value
248used is the same as that plotted in the spectral plot detailed below,
249and governed by the \texttt{spectralMethod} parameter. An example of
250what a spectral text file might look like is given below:
251
252\begin{quote}
253  {\footnotesize
254    \begin{tabular}{lllll}
255      1405.00219727  &0.01323344  &0.23648241  &0.04202826  &-0.00506790  \\
256      1405.06469727  &0.01302835  &0.27393046  &0.04686056  &-0.00471084  \\
257      1405.12719727  &0.01583361  &0.27760920  &0.04114933  &-0.01168737  \\
258      1405.18969727  &0.01271889  &0.31489247  &0.03307962  &-0.00300790  \\
259      1405.25219727  &0.01597644  &0.30401203  &0.05356426  &-0.00551653  \\
260      1405.31469727  &0.00773827  &0.30031312  &0.04074831  &-0.00570147  \\
261      1405.37719727  &0.00738304  &0.27921870  &0.05272378  &-0.00504959  \\
262      1405.43969727  &0.01353923  &0.26132512  &0.03667958  &-0.00151006  \\ 
263      1405.50219727  &0.01119724  &0.28987029  &0.03497849  &-0.00645589  \\ 
264      1405.56469727  &0.00813379  &0.29839963  &0.04711142  &0.00536576   \\ 
265      1405.62719727  &0.00774377  &0.26530230  &0.04620502  &0.00724631   \\ 
266      1405.68969727  &0.00576067  &0.23215000  &0.04995513  &0.00290841   \\
267      1405.75219727  &0.00452834  &0.16484940  &0.04261605  &-0.00612812  \\ 
268      1405.81469727  &0.01406293  &0.15989439  &0.03817926  &-0.00758385  \\
269      1405.87719727  &0.01116611  &0.11890682  &0.05499069  &-0.00626362  \\ 
270      1405.93969727  &0.00687582  &0.10620256  &0.04743370  &0.00055177   \\
271      $\vdots$       &$\vdots$    &$\vdots$    &$\vdots$    &$\vdots$     \\
272    \end{tabular}
273  }
274\end{quote}
275
276In addition to these three files, a log file can also be produced. As
277the program is running, it also (optionally) records the detections
278made in each individual spectrum or channel (see \S\ref{sec-detection}
279for details on this process). This is recorded in the file given by
280the parameter \texttt{LogFile}. This file does not include the columns
281\texttt{Name, RA, DEC, w\_RA, w\_DEC, VEL, w\_VEL}. This file is
282designed primarily for diagnostic purposes: \eg to see if a given set
283of pixels is detected in, say, one channel image, but does not survive
284the merging process. The list of pixels (and their fluxes) in the
285final detection list are also printed to this file, again for
286diagnostic purposes. The file also records the execution time, as well
287as the command-line statement used to run \duchamp. The creation of
288this log file can be prevented by setting \texttt{flagLog = false}
289(which is the default).
290
291\secB{Graphical output}
292
293\begin{figure}[t]
294  \begin{center}
295    \includegraphics[width=\textwidth]{example_spectrum}
296  \end{center}
297  \caption{\footnotesize An example of the spectral output. Note several
298    of the features discussed in the text: the red lines indicating the
299    reconstructed spectrum; the blue dashed lines indicating the
300    spectral extent of the detection; the green hashed area indicating
301    the Milky Way channels that are ignored by the searching algorithm;
302    the blue border showing its spatial extent on the 0th moment map;
303    and the 15~arcmin-long scale bar.}
304  \label{fig-spect}
305\end{figure}
306
307\begin{figure}[!t]
308  \begin{center}
309    \includegraphics[width=\textwidth]{example_moment_map}
310  \end{center}
311  \caption{\footnotesize An example of the moment map created by
312    \duchamp. The full extent of the cube is covered, and the 0th moment
313    of each object is shown (integrated individually over all the
314    detected channels). The purple line indicates the limit of the
315    non-BLANK pixels.}
316  \label{fig-moment}
317\end{figure}
318
319\secC{Mask image}
320\label{sec-maskOut}
321
322It is possible to create a FITS file containing a mask array. This
323array is designed to indicate the location of detected objects, by
324setting pixel values to 1 for pixels in a detected object and 0
325elsewhere. To create this FITS file, set the input parameter
326\texttt{flagOutputMask=true}. The file will be given the name
327\texttt{image.MASK.fits} (where the input image is called
328\texttt{image.fits}).
329
330\secC{Spectral plots}
331
332As well as the output data file, a postscript file (with the filename
333given by the \texttt{spectralFile} parameter) is created that shows
334the spectrum for each detection, together with a small cutout image
335(the 0th moment) and basic information about the detection (note that
336any flags are printed after the name of the detection, in the format
337\texttt{[E]}). If the cube was reconstructed, the spectrum from the
338reconstruction is shown in red, over the top of the original
339spectrum. The spectral extent of the detected object is indicated by
340two dashed blue lines, and the region covered by the ``Milky Way''
341channels is shown by a green hashed box. An example detection can be
342seen in Fig.~\ref{fig-spect}.
343
344The spectrum that is plotted is governed by the
345\texttt{spectralMethod} parameter. It can be either \texttt{peak} (the
346default), where the spectrum is from the spatial pixel containing the
347detection's peak flux; or \texttt{sum}, where the spectrum is summed
348over all spatial pixels, and then corrected for the beam size.  The
349spectral extent of the detection is indicated with blue lines, and a
350zoom is shown in a separate window.
351
352The cutout image can optionally include a border around the spatial
353pixels that are in the detection (turned on and off by the
354\texttt{drawBorders} parameter -- the default is \texttt{true}). It
355includes a scale bar in the bottom left corner to indicate size -- its
356length is indicated next to it (the choice of length depends on the
357size of the image).
358
359There may also be one or two extra lines on the image. A yellow line
360shows the limits of the cube's spatial region: when this is shown, the
361detected object will lie close to the edge, and the image box will
362extend outside the region covered by the data. A purple line, however,
363shows the dividing line between BLANK and non-BLANK pixels. The BLANK
364pixels will always be shown in black. The first type of line is always
365drawn, while the second is governed by the parameter
366\texttt{drawBlankEdges} (whose default is \texttt{true}), and
367obviously whether there are any BLANK pixel present.
368
369\secC{Output for 2-dimensional images}
370
371When the input image is two-dimensional, with no spectral dimension,
372this spectral plot would not make much sense. Instead, \duchamp
373creates a similar postscript file that simply includes the text
374headers as well as the 0th-moment map of the detection. As for the
375normal spectral case, this file will be written to the filename given
376by the \texttt{spectralFile} parameter.
377
378\secC{Spatial maps}
379
380Finally, a couple of images are optionally produced: a 0th moment map
381of the cube, combining just the detected channels in each object,
382showing the integrated flux in grey-scale; and a ``detection image'',
383a grey-scale image where the pixel values are the number of channels
384that spatial pixel is detected in. In both cases, if
385\texttt{drawBorders = true}, a border is drawn around the spatial
386extent of each detection, and if \texttt{drawBlankEdges = true}, the
387purple line dividing BLANK and non-BLANK pixels (as described above)
388is drawn. An example moment map is shown in Fig.~\ref{fig-moment}.
389The production or otherwise of these images is governed by the
390\texttt{flagMaps} parameter.
391
392The moment map is also displayed in a PGPlot XWindow (with the
393\texttt{/xs} display option). This feature can be turned off by
394setting \texttt{flagXOutput = false} -- this might be useful if
395running \duchamp on a terminal with no window display capability, or
396if you have set up a script to run it in a batch mode.
397
398The purpose of these images are to provide a visual guide to where the
399detections have been made, and, particularly in the case of the moment
400map, to provide an indication of the strength of the source. In both
401cases, the detections are numbered (in the same sense as the output
402list and as the spectral plots), and the spatial borders are marked
403out as for the cutout images in the spectra file. Both these images
404are saved as postscript files (given by the parameters
405\texttt{momentMap} and \texttt{detectionMap} respectively), with the
406latter also displayed in a \textsc{pgplot} window (regardless of the
407state of \texttt{flagMaps}).
Note: See TracBrowser for help on using the repository browser.