source: trunk/docs/outputs.tex @ 265

Last change on this file since 265 was 265, checked in by Matthew Whiting, 17 years ago
  • Enabled output for centroid and peak pixel locations (centroid is proper name for centre-of-mass):
    • New parameter: pixelCentre to determine preferred one for output. Needed similar parameter in the Detection class.
    • Detection::getXCentre() etc now return value based on this parameter. Have new function getXAverage() etc that accesses the average value from the Object3D.
    • Rejigged output functions so there is a difference between screen and file outputs -- screen doesn't have all the different pixel centres, but the file does.
    • Had to change the columns setup in the process.
  • Improved output for merging process.
  • Updated documentation.
File size: 14.7 KB
Line 
1\secA{Outputs}
2\label{sec-output}
3
4\secB{During execution}
5
6\duchamp provides the user with feedback whilst it is running, to
7keep the user informed on the progress of the analysis. Most of this
8consists of self-explanatory messages about the particular stage the
9program is up to. The relevant parameters are printed to the screen at
10the start (once the file has been successfully read in), so the user
11is able to make a quick check that the setup is correct (see
12Appendix~{app-input} for an example).
13
14If the cube is being trimmed (\S\ref{sec-modify}), the resulting
15dimensions are printed to indicate how much has been trimmed. If a
16reconstruction is being done, a continually updating message shows
17either the current iteration and scale, compared to the maximum scale
18(when \texttt{reconDim=3}), or a progress bar showing the amount of
19the cube that has been reconstructed (for smaller values of
20\texttt{reconDim}).
21
22During the searching algorithms, the progress through the 1D and 2D
23searches are shown. When the searches have completed, the number of
24objects found in both the 1D and 2D searches are reported (see
25\S\ref{sec-detection} for details).
26
27In the merging process (where multiple detections of the same object
28are combined -- see \S\ref{sec-merger}), two stages of output
29occur. The first is when each object in the list is compared with all
30others. The output shows two numbers: the first being how far through
31the list the current object is, and the second being the length of the
32list. As the algorithm proceeds, the first number should increase and
33the second should decrease (as objects are combined). When the numbers
34meet, the whole list has been compared. If the objects are being
35grown, a similar output is shown, indicating the progress through the
36list. In the rejection stage, in which objects not meeting the minimum
37pixels/channels requirements are removed, the total number of objects
38remaining in the list is shown, which should steadily decrease with
39each rejection until all have been examined. Note that these steps can
40be very quick for small numbers of detections.
41
42Since this continual printing to screen has some overhead of time and
43CPU involved, the user can elect to not print this information by
44setting the parameter \texttt{verbose = 0}. In this case, the user is
45still informed as to the steps being undertaken, but the details of
46the progress are not shown.
47
48There may also be Warning or Error messages printed to screen. The
49Warning messages occur when something happens that is unexpected (for
50instance, a desired keyword is not present in the FITS header), but
51not detrimental to the execution. An Error message is something more
52serious, and indicates some part of the program was not able to
53complete its task. The message will also indicate which function or
54subroutine generated it -- this is primarily a tool for debugging, but
55can be useful in determining what went wrong.
56
57\secB{Results}
58
59\secC{Table of results}
60
61Finally, we get to the results -- the reason for running \duchamp in
62the first place. Once the detection list is finalised, it is sorted by
63the mean velocity of the detections (or, if there is no good WCS
64associated with the cube, by the mean $z$-pixel position). The results
65are then printed to the screen and to the output file, given by the
66\texttt{OutFile} parameter.
67
68The output consists of three parts. First, a list of the parameters
69are printed to the output file, for future reference. Next, the
70detection level that was used is given, so comparison can be made with
71other searches. The noise level and its spread are also reported.
72
73The most interesting part, however, is the list of detected
74objects. This list, an example of which can be seen in
75Appendix~\ref{app-output}, contains the following columns (note that
76the title of the columns depending on WCS information will depend on
77the details of the WCS projection: they are shown below for the
78Equatorial and Galactic projection cases).
79
80\begin{entry}
81\item[Obj\#] The ID number of the detection (simply the sequential
82  count for the list, which is ordered by increasing velocity, or
83  channel number, if the WCS is not good enough to find the velocity).
84\item[Name] The ``IAU''-format name of the detection (derived from the
85  WCS position -- see below for a description of the format).
86\item[X] The average X-pixel position (averaged over all detected
87voxels).
88\item[Y] The average Y-pixel position.
89\item[Z] The average Z-pixel position.
90\item[RA/GLON] The Right Ascension or Galactic Longitude of the centre
91of the object.
92\item[DEC/GLAT] The Declination or Galactic Latitude of the centre of
93the object.
94\item[VEL] The mean velocity of the object [units given by the
95  \texttt{spectralUnits} parameter].
96\item[w\_RA/w\_GLON] The width of the object in Right Ascension or
97Galactic Longitude [arcmin].
98\item[w\_DEC/w\_GLAT] The width of the object in Declination Galactic
99  Latitude [arcmin].
100\item[w\_VEL] The full velocity width of the detection (max channel
101  $-$ min channel, in velocity units [see note below]).
102\item[F\_int] The integrated flux over the object, in the units of
103  flux times velocity, corrected for the beam if necessary.
104\item[F\_peak] The peak flux over the object, in the units of flux.
105\item[S/Nmax] The signal-to-noise ratio at the peak pixel.
106\item[X1, X2] The minimum and maximum X-pixel coordinates.
107\item[Y1, Y2] The minimum and maximum Y-pixel coordinates.
108\item[Z1, Z2] The minimum and maximum Z-pixel coordinates.
109\item[Npix] The number of voxels (\ie distinct $(x,y,z)$ coordinates)
110  in the detection.
111\item[Flag] Whether the detection has any warning flags (see below).
112\end{entry}
113
114The Name is derived from the WCS position. For instance, a source that
115is centred on the RA,Dec position 12$^h$53$^m$45$^s$,
116-36$^\circ$24$'$12$''$ will be given the name J125345$-$362412, if the
117epoch is J2000, or the name B125345$-$362412 if it is B1950. An
118alternative form is used for Galactic coordinates: a source centred on
119the position ($l$,$b$) = (323.1245, 5.4567) will be called
120G323.124$+$05.457. If the WCS is not valid (\ie is not present or does
121not have all the necessary information), the Name, RA, DEC, VEL and
122related columns are not printed, but the pixel coordinates are still
123provided.
124
125The velocity units can be specified by the user, using the parameter
126\texttt{spectralUnits} (enter it as a single string). The default
127value is km/s, which should be suitable for most users. These units
128are also used to give the units of integrated flux. Note that if there
129is no rest frequency specified in the FITS header, the \duchamp
130output will instead default to using Frequency, with units of MHz.
131
132If the WCS is absent or not sufficiently specified, then all columns
133from RA/GLON to w\_VEL will be left blank. Also, F\_int will be
134replaced with the more simple F\_tot -- the total flux in the
135detection, being the sum of all detected voxels.
136
137%The last column contains any warning flags about the detection. There
138%are currently three options here. An `E' is printed if the detection is
139%next to the edge of the image, meaning either the limit of the pixels,
140%or the limit of the non-BLANK pixel region. An `S' is printed if the
141%detection lies at the edge of the spectral region. An `N' is printed
142%if the total flux, summed over all the (non-BLANK) pixels in the
143%smallest box that completely encloses the detection, is negative. Note
144%that this sum is likely to include non-detected pixels. It is of use
145%in pointing out detections that lie next to strongly negative pixels,
146%such as might arise due to interference -- the detected pixels might
147%then also be due to the interference, so caution is advised.
148
149The last column contains any warning flags about the detection, such
150as:
151\begin{itemize}
152\item \textbf{E} -- The detection is next to the spatial edge of the image,
153meaning either the limit of the pixels, or the limit of the non-BLANK
154pixel region.
155\item \textbf{S} -- The detection lies at the edge of the spectral region.
156\item \textbf{N} -- The total flux, summed over all the (non-BLANK)
157pixels in the smallest box that completely encloses the detection, is
158negative. Note that this sum is likely to include non-detected
159pixels. It is of use in pointing out detections that lie next to
160strongly negative pixels, such as might arise due to interference --
161the detected pixels might then also be due to the interference, so
162caution is advised.
163\end{itemize}
164
165\secC{Other results lists}
166
167Two additional results files can also be requested. One option is a
168VOTable-format XML file, containing just the RA, Dec, Velocity and the
169corresponding widths of the detections, as well as the fluxes. The
170user should set \texttt{flagVOT = 1}, and put the desired filename in
171the parameter \texttt{votFile} -- note that the default is for it not
172to be produced. This file should be compatible with all Virtual
173Observatory tools (such as Aladin\footnote{ Aladin can be found on the
174web at
175\href{http://aladin.u-strasbg.fr/}{http://aladin.u-strasbg.fr/}}). The
176second option is an annotation file for use with the Karma toolkit of
177visualisation tools (in particular, with \texttt{kvis}). This will
178draw a circle at the position of each detection, scaled by the spatial
179size of the detection, and number it according to the Obj\# given
180above. To make use of this option, the user should set
181\texttt{flagKarma = 1}, and put the desired filename in the parameter
182\texttt{karmaFile} -- again, the default is for it not to be produced.
183
184As the program is running, it also (optionally) records the detections
185made in each individual spectrum or channel (see \S\ref{sec-detection}
186for details on this process). This is recorded in the file given by
187the parameter \texttt{LogFile}. This file does not include the columns
188\texttt{Name, RA, DEC, w\_RA, w\_DEC, VEL, w\_VEL}. This file is
189designed primarily for diagnostic purposes: \eg to see if a given set
190of pixels is detected in, say, one channel image, but does not survive
191the merging process. The list of pixels (and their fluxes) in the
192final detection list are also printed to this file, again for
193diagnostic purposes. The file also records the execution time, as well
194as the command-line statement used to run \duchamp. The creation of
195this log file can be prevented by setting \texttt{flagLog = false}.
196
197\secC{Graphical output -- spectra}
198
199\begin{figure}[t]
200\begin{center}
201\includegraphics[width=\textwidth]{example_spectrum}
202\end{center}
203\caption{\footnotesize An example of the spectrum output. Note several
204  of the features discussed in the text: the red lines indicating the
205  reconstructed spectrum; the blue dashed lines indicating the
206  spectral extent of the detection; the green hashed area indicating
207  the Milky Way channels that are ignored by the searching algorithm;
208  the blue border showing its spatial extent on the 0th moment map;
209  and the 15~arcmin-long scale bar.}
210\label{fig-spect}
211\end{figure}
212
213\begin{figure}[!t]
214\begin{center}
215\includegraphics[width=\textwidth]{example_moment_map}
216\end{center}
217\caption{\footnotesize An example of the moment map created by
218  \duchamp. The full extent of the cube is covered, and the 0th moment
219  of each object is shown (integrated individually over all the
220  detected channels). The purple line indicates the limit of the
221  non-BLANK pixels.}
222\label{fig-moment}
223\end{figure}
224
225As well as the output data file, a postscript file is created that
226shows the spectrum for each detection, together with a small cutout
227image (the 0th moment) and basic information about the detection (note
228that any flags are printed after the name of the detection, in the
229format \texttt{[E]}). If the cube was reconstructed, the spectrum from
230the reconstruction is shown in red, over the top of the original
231spectrum. The spectral extent of the detected object is indicated by
232two dashed blue lines, and the region covered by the ``Milky Way''
233channels is shown by a green hashed box. An example detection can be
234seen below in Fig.~\ref{fig-spect}.
235
236The spectrum that is plotted is governed by the
237\texttt{spectralMethod} parameter. It can be either \texttt{peak} (the
238default), where the spectrum is from the spatial pixel containing the
239detection's peak flux; or \texttt{sum}, where the spectrum is summed
240over all spatial pixels, and then corrected for the beam size.  The
241spectral extent of the detection is indicated with blue lines, and a
242zoom is shown in a separate window.
243
244The cutout image can optionally include a border around the spatial
245pixels that are in the detection (turned on and off by the
246\texttt{drawBorders} parameter -- the default is \texttt{true}). It
247includes a scale bar in the bottom left corner to indicate size -- its
248length is indicated next to it (the choice of length depends on the
249size of the image).
250
251There may also be one or two extra lines on the image. A yellow line
252shows the limits of the cube's spatial region: when this is shown, the
253detected object will lie close to the edge, and the image box will
254extend outside the region covered by the data. A purple line, however,
255shows the dividing line between BLANK and non-BLANK pixels. The BLANK
256pixels will always be shown in black. The first type of line is always
257drawn, while the second is governed by the parameter
258\texttt{drawBlankEdges} (whose default is \texttt{true}), and
259obviously whether there are any BLANK pixel present.
260
261\secC{Graphical output -- maps}
262
263Finally, a couple of images are optionally produced: a 0th moment map
264of the cube, combining just the detected channels in each object,
265showing the integrated flux in grey-scale; and a ``detection image'',
266a grey-scale image where the pixel values are the number of channels
267that spatial pixel is detected in. In both cases, if
268\texttt{drawBorders = true}, a border is drawn around the spatial
269extent of each detection, and if \texttt{drawBlankEdges = true}, the
270purple line dividing BLANK and non-BLANK pixels (as described above)
271is drawn. An example moment map is shown in Fig.~\ref{fig-moment}.
272The production or otherwise of these images is governed by the
273\texttt{flagMaps} parameter.
274
275The moment map is also displayed in a PGPlot XWindow. This feature can
276be turned off by setting the \texttt{flagXOutput} parameter to
277\texttt{false} -- this might be useful if running \duchamp on a
278terminal with no window display capability, or if you have set up a
279script to run it in a batch mode.
280
281The purpose of these images are to provide a visual guide to where the
282detections have been made, and, particularly in the case of the moment
283map, to provide an indication of the strength of the source. In both
284cases, the detections are numbered (in the same sense as the output
285list and as the spectral plots), and the spatial borders are marked
286out as for the cutout images in the spectra file. Both these images
287are saved as postscript files (given by the parameters
288\texttt{momentMap} and \texttt{detectionMap} respectively), with the
289latter also displayed in a \textsc{pgplot} window (regardless of the
290state of \texttt{flagMaps}).
Note: See TracBrowser for help on using the repository browser.