source: trunk/docs/outputs.tex @ 160

Last change on this file since 160 was 160, checked in by Matthew Whiting, 18 years ago

Changed the way the FITS file is read in, so that it can deal with
naxis>4 files, where the order of the dimensions is not necessarily
lng,lat,spec,...

Summary of changes:

*Cubes/getImage.cc:

*Removed most of the code that goes in new functions.
*Changed order of tasks, so that the WCS is derived first, then the data array, and then the remaining header information.
*Also reports both the FITS dimensions and the data array dimensions.

*FitsIO/headerIO.cc:

*Moved defineWCS to wcsIO.cc.
*Made array declarations more robust (use CFITSIO constants for lengths).
*Changed type of BLANK keyword to TINT.

*FitsIO/dataIO.cc:

*New function, designed to read in data from FITS file.
*Reads in subset of just the spatial and spectral axes.
*Also takes care of setting blank pixels to appropriate value.

*FitsIO/wcsIO.cc:

*New file, contains the function FitsHeader::defineWCS

  • Utils/wcsFunctions.cc:

*Generalised the wcs functions, so that they make no

assumptions about the location of the spatial and spectral axes.

*Cubes/cubes.cc:

*Improved Cube::initialiseCube so that it gets the dimensions correct.
*Enabled Cube::getopts to deal with non-existant param file.
*Improved error reporting in saveArray functions.

*Cubes/cubes.hh:

*Changed prototypes for readParam. Added one for getFITSdata

*Cubes/ReadAndSearch?.cc :

*Minor comment added.

*param.cc:

*Generalised way fixUnits works, to cope with new axis concept.
*Made readParams return int, so it can indicate whether reading failed.

*ATrous/ReconSearch.cc:

*Improved way the goodness of the pixels and channels was determined.

*src/param.hh

*New prototype for Param::readParams

*Guide:

*Changed text about dimensionality of FITS files.
*Changed location of images.
*Minor changes to improve readability.

File size: 12.6 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 (\ie the whole list has been compared), the second phase begins,
35in which multiply-appearing pixels in each object are removed, as are
36objects not meeting the minimum channels requirement. During this
37phase, the total number of accepted objects is shown, which should
38steadily increase until all have been accepted or rejected. Note that
39these steps can be very quick for small numbers of detections.
40
41Since this continual printing to screen has some overhead of time and
42CPU involved, the user can elect to not print this information by
43setting the parameter \texttt{verbose = 0}. In this case, the user is
44still informed as to the steps being undertaken, but the details of
45the progress are not shown.
46
47\secB{Results}
48
49\secC{Table of results}
50
51Finally, we get to the results -- the reason for running \duchamp\ in
52the first place. Once the detection list is finalised, it is sorted by
53the mean velocity of the detections (or, if there is no good WCS
54associated with the cube, by the mean Z-pixel position). The results
55are then printed to the screen and to the output file, given by the
56\texttt{OutFile} parameter. The results list, an example of which can
57be seen in Appendix~\ref{app-output}, contains the following columns
58(note that the title of the columns depending on WCS information will
59depend on the projection of the WCS):
60
61\begin{entry}
62\item[Obj\#] The ID number of the detection (simply the sequential
63  count for the list, which is ordered by increasing velocity, or
64  channel number, if the WCS is not good enough to find the velocity).
65\item[Name] The ``IAU''-format name of the detection (derived from the
66  WCS position -- see below for a description of the format).
67\item[X] The average X-pixel position (averaged over all detected
68voxels).
69\item[Y] The average Y-pixel position.
70\item[Z] The average Z-pixel position.
71\item[RA/GLON] The Right Ascension or Galactic Longitude of the centre
72of the object.
73\item[DEC/GLAT] The Declination or Galactic Latitude of the centre of
74the object.
75\item[VEL] The mean velocity of the object [units given by the
76  \texttt{spectralUnits} parameter].
77\item[w\_RA/w\_GLON] The width of the object in Right Ascension or
78Galactic Longitude [arcmin].
79\item[w\_DEC/w\_GLAT] The width of the object in Declination Galactic
80  Latitude [arcmin].
81\item[w\_VEL] The full velocity width of the detection (max channel
82  $-$ min channel, in velocity units [see note below]).
83\item[F\_int] The integrated flux over the object, in the units of
84  flux times velocity, corrected for the beam if necessary.
85\item[F\_peak] The peak flux over the object, in the units of flux.
86\item[X1, X2] The minimum and maximum X-pixel coordinates.
87\item[Y1, Y2] The minimum and maximum Y-pixel coordinates.
88\item[Z1, Z2] The minimum and maximum Z-pixel coordinates.
89\item[Npix] The number of voxels (\ie distinct $(x,y,z)$ coordinates)
90  in the detection.
91\item[Flag] Whether the detection has any warning flags (see below).
92\end{entry}
93The Name is derived from the WCS position. For instance, a source
94centred on the RA,Dec position 12$^h$53$^m$45$^s$,
95-36$^\circ$24$'$12$''$ will be called J125345$-$362412 (if the epoch
96is J2000) or B125345$-$362412 (if B1950). An alternative form is used
97for Galactic coordinates: a source centred on the position ($l$,$b$) =
98(323.1245, 5.4567) will be called G323.124$+$05.457. If the WCS is not
99valid (\ie is not present or does not have all the necessary
100information), the Name, RA, DEC, VEL and related columns are not
101printed, but the pixel coordinates are still provided.
102
103The velocity units can be specified by the user, using the parameter
104\texttt{spectralUnits} (enter it as a single string). The default
105value is km/s, which should be suitable for most users. These units
106are also used to give the units of integrated flux. Note that if there
107is no rest frequency specified in the FITS header, the \duchamp\
108output will instead default to using Frequency, with units of MHz.
109
110If the WCS is not specified sufficiently to be used, then all columns
111from RA/GLON to w\_VEL will be left blank. Also, F\_int will be
112replaced with the more simple F\_tot -- the total flux in the
113detection, being the sum of all detected voxels.
114
115The last column contains any warning flags about the detection. There
116are currently two options here. An `E' is printed if the detection is
117next to the edge of the image, meaning either the limit of the pixels,
118or the limit of the non-BLANK pixel region. An `N' is printed if the
119total flux, summed over all the (non-BLANK) pixels in the smallest box
120that completely encloses the detection, is negative. Note that this
121sum is likely to include non-detected pixels. It is of use in pointing
122out detections that lie next to strongly negative pixels, such as
123might arise due to interference -- the detected pixels might then also
124be due to the interference, so caution is advised.
125
126\secC{Other results lists}
127
128Two alternative results files can also be requested. One option is a
129VOTable-format XML file, containing just the RA, Dec, Velocity and the
130corresponding widths of the detections, as well as the fluxes. The
131user should set \texttt{flagVOT = 1}, and put the desired filename in
132the parameter \texttt{votFile} -- note that the default is for it not
133to be produced. This file should be compatible with all Virtual
134Observatory tools (such as Aladin\footnote{ Aladin can be found on the
135web at
136\href{http://aladin.u-strasbg.fr/}{http://aladin.u-strasbg.fr/}}). The
137second option is an annotation file for use with the Karma toolkit of
138visualisation tools (in particular, with \texttt{kvis}). This will
139draw a circle at the position of each detection, and number it
140according to the Obj\# given above. To make use of this option, the
141user should set \texttt{flagKarma = 1}, and put the desired filename
142in the parameter \texttt{karmaFile} -- again, the default is for it
143not to be produced.
144
145As the program is running, it also (optionally) records the detections
146made in each individual spectrum or channel (see \S\ref{sec-detection}
147for details on this process). This is recorded in the file given by
148the parameter \texttt{LogFile}. This file does not include the columns
149\texttt{Name, RA, DEC, w\_RA, w\_DEC, VEL, w\_VEL}. This file is
150designed primarily for diagnostic purposes: \eg to see if a given set
151of pixels is detected in, say, one channel image, but does not survive
152the merging process. The list of pixels (and their fluxes) in the
153final detection list are also printed to this file, again for
154diagnostic purposes. The file also records the execution time, as well
155as the command-line statement used to run \duchamp. The creation of
156this log file can be prevented by setting \texttt{flagLog =
157false}. (This may be a good idea if you are not interested in its
158contents, as it can be a large file if many pixels are being
159detected.)
160
161\secC{Graphical output -- spectra}
162
163\begin{figure}[t]
164\begin{center}
165\includegraphics[width=\textwidth]{example_spectrum}
166\end{center}
167\caption{\footnotesize An example of the spectrum output. Note several
168  of the features discussed in the text: the red lines indicating the
169  reconstructed spectrum; the blue dashed lines indicating the
170  spectral extent of the detection; the green hashed area indicating
171  the Milky Way channels that are ignored by the searching algorithm;
172  the blue border showing its spatial extent on the 0th moment map;
173  and the 15~arcmin-long scale bar.}
174\label{fig-spect}
175\end{figure}
176
177\begin{figure}[!t]
178\begin{center}
179\includegraphics[width=\textwidth]{example_moment_map}
180\end{center}
181\caption{\footnotesize An example of the moment map created by
182  \duchamp. The full extent of the cube is covered, and the 0th moment
183  of each object is shown (integrated individually over all the
184  detected channels). The purple line indicates the limit of the
185  non-BLANK pixels.}
186\label{fig-moment}
187\end{figure}
188
189As well as the output data file, a postscript file is created that
190shows the spectrum for each detection, together with a small cutout
191image (the 0th moment) and basic information about the detection (note
192that any flags are printed after the name of the detection, in the
193format \texttt{[E]}). If the cube was reconstructed, the spectrum from
194the reconstruction is shown in red, over the top of the original
195spectrum. The spectral extent of the detected object is indicated by
196two dashed blue lines, and the region covered by the ``Milky Way''
197channels is shown by a green hashed box. An example detection can be
198seen below in Fig.~\ref{fig-spect}.
199
200The spectrum that is plotted is governed by the
201\texttt{spectralMethod} parameter. It can be either \texttt{peak},
202where the spectrum is from the spatial pixel containing the
203detection's peak flux; or \texttt{sum}, where the spectrum is summed
204over all spatial pixels, and then corrected for the beam size.  The
205spectral extent of the detection is indicated with blue lines, and a
206zoom is shown in a separate window.
207
208The cutout image can optionally include a border around the spatial
209pixels that are in the detection (turned on and off by the parameter
210\texttt{drawBorders} -- the default is \texttt{true}). It includes a
211scale bar in the bottom left corner to indicate size -- its length is
212indicated next to it (the choice of length depends on the size of the
213image).
214
215There may also be one or two extra lines on the image. A yellow line
216shows the limits of the cube -- the detected object is obviously close
217to the edge of the cube, and the box size extends outside the region
218covered by the data. A purple line, however, shows the dividing line
219between BLANK and non-BLANK pixels. The BLANK pixels will always be
220shown in black. The first type of line is always drawn, while the
221second is governed by the parameter \texttt{drawBlankEdges} (whose
222default is \texttt{true}), and obviously whether there are any BLANK
223pixel present.
224
225\secC{Graphical output -- maps}
226
227Finally, a couple of images are optionally produced: a 0th moment map
228of the cube, combining just the detected channels in each object,
229showing the integrated flux in grey-scale; and a ``detection image'',
230a grey-scale image where the pixel values are the number of channels
231that spatial pixel is detected in. In both cases, if
232\texttt{drawBorders = true}, a border is drawn around the spatial
233extent of each detection, and if \texttt{drawBlankEdges = true}, the
234purple line dividing BLANK and non-BLANK pixels (as described above)
235is drawn. An example moment map is shown in Fig.~\ref{fig-moment}.
236The production or otherwise of these images is governed by the
237\texttt{flagMaps} parameter.
238
239The purpose of these images are to provide a visual guide to where the
240detections have been made, and, particularly in the case of the moment
241map, to provide an indication of the strength of the source. In both
242cases, the detections are numbered (in the same sense as the output
243list and as the spectral plots), and the spatial borders are marked
244out as for the cutout images in the spectra file. Both these images
245are saved as postscript files (given by the parameters
246\texttt{momentMap} and \texttt{detectionMap} respectively), with the
247latter also displayed in a \textsc{pgplot} window (regardless of the
248state of \texttt{flagMaps}).
Note: See TracBrowser for help on using the repository browser.