7.8. Recipes for mapping observations

An FTS observation of the Orion Bar is used throughout this section to illustrate an extended source observed in fully sampled mapping mode. The observation used is from operational day (OD) 495, with observation ID (obsid) 1342204919, and can be obtained from the Herschel Science Archive.

The FTS pipeline for mapping observations produces two sets of SpectralSimpleCubes for each detector array. Each set is created using a different projection algorithm, although both project the measured detector data onto an equivalent rectangular, equidistant grid. The following sections describe aspects of data reduction to consider for FTS observations taken in intermediate and fully sampled mapping modes:

A notable aspect of FTS mapping is the two unusable detectors in SSW (SSWD5 and SSWF4), which marginally reduce coverage. Another coverage related issue to consider is the outer ring of detectors in both arrays, as these are partially vignetted (see the SPIRE Handbook). In order to provide the largest possible gridded area, these detectors are included in the pipeline cube creation step. However, some of these detectors have lower than average sensitivity and higher than average systematic noise, as discussed in Hopwood et al. 2015. If the map in question is of a relatively faint source, it may be worth regridding the spectral cubes in order to exclude the partially vignetted detectors. This can be achieved by setting unvignetted = True when calling spirePreprocessCube, which creates the 2D list of spectra for projecting. From HIPE version 14.1, a correction for artefacts in LR SLW data is propagated to the extended-source calibrated spectra. This is an empirical correction derived using LR point-source calibrated data (see Marchili et al. 2016 for details). As there is no point-source conversion for the vignetted detectors, the vignetted detectors are uncorrected and therefore not included for LR SLW cubes processed with HIPE version 14.1 (or later). This is true for the LR SLW cubes from H+LR observations, so there is a difference in area with the corresponding HR SLW cubes.

The Spectrometer Thumbnail Mosaic Plot script is useful for plotting many detectors from data taken during a single pointing measurement. It can be edited for use with mapping observations, in order to display the spectra taken at each jiggle position. The script allows the spectra from all detectors in the array to be plotted as they appear on the array footprint. See Section 7.2.3.2 for more details.

7.8.1. Understanding the SPIRE beam and how it relates to mapping observations

The FTS beam is frequency dependant, as shown in Section 7.6.1, and described by two calibration products that have a frequency scale corresponding to the frequency axis of the spectrum. SCalSpecBeamProf contains the 2D-beam shapes and SCalSpecBeamParam contains the beam FWHM. SCalSpecBeamParam also contains the point-source calibration factors, which are dependent on spectral resolution and OD. The dependency on OD is not because of any change in the beam FWHM, but due to a difference in the point-source calibration for observations taken before OD 1011 and those taken after, as explained in Section 7.4.1. The appropriate beam parameter calibration product for a particular observation can be obtained from the calibration Context using any Level-2 product, for example, if using a spectral cube, beamParam can be obtained from an Observation Context (obs) as:

beamParam = obs.calibration.spec.beamParamList.getProduct(cube)

This calibration product can also be extracted by specifying the resolution and date of the observation, for example,

beamParam = obs.calibration.spec.beamParamList.getProduct("HR", obs.startDate)

For a particular detector (e.g. SSWD4) the beam diameter column can be accessed from beamParam as

beamDiam = beamParam["0000"]["SSWD4"].beamDiam

The beam diameter corresponds to the 2D-beam shapes that are stored in the SCalSpecBeamProf calibration product, which were derived by moving the telescope over the planet Neptune. The beam shapes can be obtained from the calibration tree, e.g. for SSW:

beamProfSsw = obs.calibration.spec.beamProfList.getProduct("SSW")

The resulting product can be viewed with the Spectrum Explorer in the same way as for Spectral Cube products. The beam shapes are Gaussian for SSW, but not for SLW above 700 GHz. Full details of the beam profiles are given in Makiwa et al. (2013), Applied Optics, 52, 3864.

Note that from HIPE version 12 onwards, FTS spectra are corrected to the Local Standard of Rest (LSR) by the pipeline. This correction is carried out towards the end of the pipeline, which means that although the frequency axis of the calibration product and the final spectra will match, there may be a small linear shift compared to the actual values applied.

7.8.2. Check clipping

Clipping due to saturation of the electronics may provide an explanation for more holes in a spectral cube than expected. Detectors with severely or totally clipped interferograms are removed from the final data products by the pipeline, after which nothing can be done to recover the data. This section should allow you to determine if an observation has suffered clipping in this way.

Clipping occurs when the signal received by a detector is outside the dynamic range of the electronics, which causes truncation in the detected interferograms. Clipped samples are flagged in the mask table attached to the data as TRUNCATED. Details of the SPIRE masks and mask handling are given in Section 8.4. If the truncation is not too severe, the clipping correction task generally works well to reconstruct the missing parts of an interferogram, using an 8th order polynomial fit. In tests where the interferogram was clipped, such that the 4th lobe away from zero path difference was affected, the spectrum was corrected to better than 3%. This means that clipping should not be an issue for most observations.

Cases of more severe clipping may occur for maps of relatively bright sources, if large flux density gradients were observed with nominal detector bias settings. For maps taken in nominal mode, the dynamic range of the detectors is set using the observed signal at the beginning of the observation (see Section 7.1.2), which means the detector offset level is determined only at the first jiggle position. If the source brightness changes significantly for subsequent jiggle positions, some detectors may become unusable and will be removed from the data products by the pipeline. The createIfgm task removes samples that are clipped at the high and low OPD (optical path difference) ends of the interferogram. If all samples are removed, then so is the entire interferogram (i.e. one scan) for that detector. If all scans are removed, the detector will no longer appears in the output product. The baselineCorrection task will remove any scan that has fewer than 100 samples.

The final spectrum may be affected by scans where some samples were clipped at high OPD and removed, but not enough to see the whole scan removed. The example observation of the Orion Bar (1342192173) suffered clipping in SSWD1, as illustrated by Figure 7.55. This figure shows the Level-0.5 data from the detector in question, in jiggle position 13. This detector is in the outer ring, where partial vignetting introduced a slope to the interferogram baseline (see Section 7.3.15). Some samples at the high OPD end are clipped, which reduces the OPD range of the interferogram and therefore results in a decrease of the spectral resolution. The final spectrum for this position shows broader lines than for the surrounding detectors and should be removed before the cube is created and any line fitting is performed. The spectral resolution can be checked in the pre-processed cube product (which collates the individual extended-source calibrated spectra), where the resolution is recorded for each spectrum in the "resolution" column. In the individual extended-source calibrated spectra (SDS products), the spectral resolution is recorded in the actualResolution metadata item, which is attached to each detector dataset. For spectral cubes, the actualResolution reports the highest spectral resolution present for all the spectra in the pre-processed cube. Therefore you can check the cube actualResolution to see if there is at least one spectrum in the associated pre-processed cube that has a degraded spectral resolution, i.e. greater than 1.184 GHz for HR and 26.77 GHz for LR.

On the left, the Level-0.5 data for a clipped detector (SSWD1) in jiggle position 13 of obsid 1342192173 are plotted in the Detector Timeline Explorer. On the right, the final extended-source calibrated SSWD1 spectrum is compared to the unclipped SSWC1 spectrum, plotted using the SDS Explorer. The interferogram data shows truncation both near to zero path difference, which has been corrected by the pipeline, and at high OPD, which has been removed by pipeline. The reduction in OPD range causes the final spectrum to be reduced in spectral resolution (as if it had been apodized).

Figure 7.55. On the left, the Level-0.5 data for a clipped detector (SSWD1) in jiggle position 13 of obsid 1342192173 are plotted in the Detector Timeline Explorer. On the right, the final extended-source calibrated SSWD1 spectrum is compared to the unclipped SSWC1 spectrum, plotted using the SDS Explorer. The interferogram data shows truncation both near to zero path difference, which has been corrected by the pipeline, and at high OPD, which has been removed by pipeline. The reduction in OPD range causes the final spectrum to be reduced in spectral resolution (as if it had been apodized).


In order to verify that clipping is the underlying cause for data missing from the final data products, it is necessary to examine the Level-0.5 timelines, for example using the Detector Timeline Viewer (see Section 8.2), or to look at the Level-1 interferogram product using the Spire Mask Editor Tool (see Section 8.4). It should be obvious if an interferogram has been terminally truncated, because there will be a completely flat baseline with little or no signal at zero path difference. There is no way to recover the data for such cases.

7.8.3. Pointing Information

For a mapping observation, information on pointing can be examined by extracting the Spectrum2d dataset contained inside the preCube product, which can be achieved either using the Product Viewer or by running the following command:

mySpectrum2d = preCube.spectrum2d

The RA and Dec for each spectrum are contained in the longitude and latitude columns of mySpectrum2d.

mySpectrum2d can be visually inspected by right clicking on it in the variables tab and opening with the Spectrum Explorer (see Figure 7.56).

Displaying the Spectrum2d dataset extracted from a preCube, in the Spectrum Explorer. The RA and Dec for each spectrum is shown, and individual spectra can be plotted by clicking in the second column labeled "0". Double-clicking on the "0" column title will deselect or select all spectra.

Figure 7.56. Displaying the Spectrum2d dataset extracted from a preCube, in the Spectrum Explorer. The RA and Dec for each spectrum is shown, and individual spectra can be plotted by clicking in the second column labeled "0". Double-clicking on the "0" column title will deselect or select all spectra.


For SSW, the two dead detectors (SSWD5 and SSWF4) lead to less even coverage of observed sky positions across the field of view. Figure 7.57 shows a plot of the observed coordinate positions for the fully sampled Orion Bar observation for SSW and SLW. This plot can be generated with the following:

from herschel.ia.gui.plot.renderer.axtype import AxisType
    
mySpectrum2d = preCube.spectrum2d
p=PlotXY(mySpectrum2d["longitude"].data, mySpectrum2d["latitude"].data)
p.setLine(0)
p.firstLayerXY.setXAxisType(AxisType.RIGHT_ASCENSION)
p.firstLayerXY.setYAxisType(AxisType.DECLINATION)
p.setXtitle("RA [hh:mm:ss]")
p.setYtitle("DEC [dd:mm:ss]")

The positions observed on the sky can also be examined from within the Spectrum Explorer, using the Mosaic (or Raster) Tab, as explained in the Spectrum Explorer section of the Herschel Data Analysis Guide.

The actual positions observed on the sky for the fully sampled example observation of the Orion Bar. SSW is on the left and SLW on the right.

Figure 7.57. The actual positions observed on the sky for the fully sampled example observation of the Orion Bar. SSW is on the left and SLW on the right.


7.8.4. Restricting or expanding the data for gridding

Prior to gridding, the pipeline collates the individual extended-source calibrated spectra (SDS) into a SpirePreprocessedCube product, which is the pre-processed cube and labelled as the preCube in the pipeline. The preCube is a listing of all spectra and positions in a Spectrum2d format. All detectors are included in the preCube, but there are some basic options (methods) that allow data to be removed. Individual or selected groups of spectra can be removed using the deleteSpectra method and specifying the detector name(s), jiggle ID and raster ID. For example:

# Remove all SSWD1 spectra from all jiggle/raster positions:
preCube.deleteSpectra("SSWD1")
# Remove all spectra from jiggle position 13, raster position 0:
preCube.deleteSpectra(13, 0)
# Remove SSWD1 from jiggle position 13, raster position 0:
preCube.deleteSpectra("SSWD1", 13, 0)
# Multiple detector name can also be specified in a list:
preCube.deleteSpectra(["SSWD1", "SSWC2"], 13, 0)

Note that jiggle and raster ID start at 0, and if the specified spectrum doesn't exist (or the jiggle or raster ID are specified incorrectly), nothing will be removed.

The spectra in a preCube can be extracted as an array of SpireSpectrum1d objects using the extractSpectra method. The syntax for specifying which spectrum (or spectra) to extract is similar to that for deleteSpectra:

# Extract all SSWD1 spectra from all jiggle/raster positions:
spectraArray = preCube.extractSpectra("SSWD1")
# Extract all spectra from jiggle position 13, raster position 0:
spectraArray = preCube.extractSpectra(13, 0)
# Extract SSWD1 from jiggle position 13, raster position 0:
spectraArray = preCube.extractSpectra("SSWD1", 13, 0)
# Multiple detector names can also be specified in a list:
spectraArray = preCube.extractSpectra(["SSWD1", "SSWC2"], 13, 0)
# Get the first SpireSpectrum1d from the array:
spectrum1d = spectraArray[0]

Several observations can be combined into a single cube by combining two or more preCubes, following:

preCube = preCube1.append(preCube2)

Once all of the required spectra are contained in a single preCube product, they can be gridded into a cube using SpecWcsCreator and spireProjection (see Section 7.8.5). For example, if using the Naive projection algorithm:

wcs = SpecWcsCreator.createWcs(preCube, gridSpacingX, gridSpacingY)
combinedCube = spireProjection(spc=preCube, wcs=wcs, projectionType="naive")

Observations processed with a pipeline version prior to HIPE 13, will not have the preCube saved inside the Observation Context, with the individual SDS products stored in the Level-1 Context instead. This change in format, combined with a correction for the extended calibration (as explained in Valtchanov et al. 2016), which was introduced for HIPE 14, means that it is essential for all mapping observations to be updated to HIPE 14 processed data. If the observation in the Herschel Science Archive has been reduced with HIPE version 14, it can be downloaded directly. If the version is HIPE 13, then use the on-demand reprocessing option or run the HIPE 14 User Pipeline mapping script . For the latter option, it does not matter if the data is not in the HIPE version 13 and later Observation Context format, as the script will automatically update the Context to the new format.

7.8.5. The gridding algorithms

There are currently four SPIRE compatible gridding algorithms available in HIPE, which are listed in Table 7.6. Each gridding algorithm (also called projection algorithm) requires an RA and Dec grid specified as a WCS object. The WCS is set up using a preCube and desired grid spacing in degrees, e.g, for a grid with 17.5'' pixel size:

wcs = SpecWcsCreator.createWcs(preCube, 17.5/3600.0, 17.5/3600.0)

The way the samples are mapped onto the WCS grid can be examined by overplotting the grid lines on top of the observed data points. The following script was used to produce Figure 7.58, where grid lines have been added to the SSW plot from Figure 7.57:

start = wcs.getWorldCoordinates(0,0)
end   = wcs.getWorldCoordinates(wcs.naxis2, wcs.naxis1)
xstep = wcs.cdelt1/COS((start[1])*Math.PI/180.)
ystep = wcs.cdelt2
for i in range(wcs.naxis1+1):    
    xGridLine = start[0] + xstep*i - xstep/2
    p.addLayer(LayerXY(Double1d([xGridLine, xGridLine]), \
                       Double1d([start[1], end[1]])-ystep/2, \
                       color=java.awt.Color.GRAY))
for i in range(wcs.naxis2+1):
    yGridLine = start[1] + ystep*i - ystep/2
    p.addLayer(LayerXY(Double1d([start[0], end[0]])-xstep/2, \
              Double1d([yGridLine, yGridLine]), color=java.awt.Color.GRAY))
The observed SSW sky positions for the example Orion Bar observation (Figure 7.57), overlaid with a WCS grid to illustrate how the individual spectra are gridded to create a spectral cube, where each grid square corresponds to a cube spectral pixel.

Figure 7.58. The observed SSW sky positions for the example Orion Bar observation (Figure 7.57), overlaid with a WCS grid to illustrate how the individual spectra are gridded to create a spectral cube, where each grid square corresponds to a cube spectral pixel.


The WCS can be set up by forcing the reference pixel to be at a specified RA and Dec. For example, the following command will put the reference pixel at the crval1 and crval2 RA and Dec of [83.849707, -5.397227].

wcs = SpecWcsCreator.createWcs(preCube, 83.849707, -5.397227, \
                                                   17.5/3600.0, 17.5/3600.0)

The WCS can also be constructed in instrument coordinates rather than RA and Dec, which rotates the image to match the satellite Y and Z axes. One example where this might be useful, is to check the position of missing pixels in the map against the locations of the two dead detectors in the SSW array. The gaps from these detectors (SSWD5 and SSWF4) are always in the same part of the map when working in instrument coordinates. A WCS in instrument coordinates can be constructed by setting useDetCoords to True:

wcs = SpecWcsCreator.createWcs(preCube, 17.5/3600.0, 17.5/3600.0, True)

Table 7.6. Cube projection algorithms available for SPIRE data.

Task name Algorithm details SPIRE Pipeline Specification Manual entry Comments
nearestNeighbourProjection Nearest spectrum to grid square centre is used. No averaging or interpolation. Nearest Neighbour Spatial Projection The spectrum closest to the centre of a grid square is used, even if its position is not inside the grid square. Not generally recommended.
naiveProjection (same algorithm as for the SPIRE Photometer map maker) Mean sum of spectra falling within a grid square. No interpolation. Naive Spatial Projection Empty grid squares are set to NaN. Used in the standard FTS pipeline.
convolutionProjection Each grid square is assigned the Gaussian weighted contribution of all spectra falling within the kernel area. Convolution Spatial Projection Grid squares assigned a Gaussian weighted contribution from spectra within the kernel. Used in the standard FTS pipeline.
griddingProjection (a wrapper for the HIFI gridding task) Per grid square, averaging and interpolation of all spectra using a convolution kernel to model the beam profile Gridding Spatial Projection (also see the HIFI User's Manual) A SPIRE wrapper to use the HIFI task for On-The-Fly maps. A HIFI build is required. This algorithm should not be used for intermediate sampled FTS mapping observations.

These algorithms can be applied using spireProjection or with the tasks shown in Table 7.6. When using spireProjection, the projectionType can be nearest, naive, convolution or gridding (see the SPIRE Pipeline Specification Manual - SPIRE Projection). For example:

cube = spireProjection(spc=preCube, wcs=wcs, projectionType="naive")

The standard pipeline creates two sets of spectral cubes. One set uses the Naive projection algorithm, which takes the mean sum of spectra falling within a grid square. The other set uses the convolution projection algorithm, which for each grid square, sums the Gaussian weighted contribution from spectra falling within the area of the weight kernel. This figure illustrates the final Naive cube. For the convolution projected cube: the "flux" is the weighted mean of spectra within the kernel; the "error" is the weighted error; the "coverage" is likewise weighted and uses the default minimum limit of 0.1.

Figure 7.59. The standard pipeline creates two sets of spectral cubes. One set uses the Naive projection algorithm, which takes the mean sum of spectra falling within a grid square. The other set uses the convolution projection algorithm, which for each grid square, sums the Gaussian weighted contribution from spectra falling within the area of the weight kernel. This figure illustrates the final Naive cube. For the convolution projected cube: the "flux" is the weighted mean of spectra within the kernel; the "error" is the weighted error; the "coverage" is likewise weighted and uses the default minimum limit of 0.1.


Two sets of spectral cubes are created by the standard pipeline, with each set containing one cube per detector array. One set of cubes is created with the Naive projection algorithm, which is the same map making algorithm used for the SPIRE photometer maps (the NaiveMapper). This projection calculates the mean sum for all spectra located within one grid square (a spectral pixel or "spaxel"), as illustrated by Figure 7.59. Empty grid squares are left blank, with the corresponding spaxel set to NaN. The other set of cubes is generated using the Convolution projection algorithm, which results in more complete coverage, i.e. there are no NaN "holes" within the main body of the grid for a Convolution projected (CP) cube. For each spaxel, this projection sums the Gaussian weighted contribution from all spectra in the relevant detector array that fall within the kernel. The Gaussian kernel used is set to a FWHM of the beam diameter and limited to a width of twice this. Although there are no holes spatially (i.e. per layer) in the resulting cubes, because the beam width is frequency dependent, so is the coverage. Therefore, as there is a minimum allowed coverage of 0.1, there can be holes spectrally at the map edges. The FTS beam is smaller towards the middle of each band, so these spectral gaps occur towards the centre of the frequency bands. However, such partial spectra are few in number and confined to the edges of the cube grid.

Figure 7.60 shows a comparison of the naive SSW and the CP SSW cubes for the example Orion Bar observation. The cube map at 1200 GHz is overlaid by the FTS footprint for the central Jiggle position and the position of the individual spectra that were projected into each grid square. For the naive cube, the "holes" correspond to zero spectra within a spaxel, whereas for the CP cube there are no holes and the map has a smoother appearance.

SSW cube maps at 1200 GHz. Both cubes are overlaid with the FTS footprint for the central Jiggle position (pink circles) and all the positions of the ungridded spectra (green pluses). On the left is the naive projected cube and on the right is the convolution projected cube, which is smoother with no "holes"."

Figure 7.60. SSW cube maps at 1200 GHz. Both cubes are overlaid with the FTS footprint for the central Jiggle position (pink circles) and all the positions of the ungridded spectra (green pluses). On the left is the naive projected cube and on the right is the convolution projected cube, which is smoother with no "holes"."


The Convolution projection task has a default kernel size of 35" for SLW or 19" for SSW but the size can be set explicitly. As in the FTS mapping pipeline, a frequency dependent convolution kernel width can be used, e.g., calculated from the beam diameters in the SCalSpecBeamParam calibration product (see Section 7.12.5):

cube = spireProjection(spc=preCube, wcs=wcs, projectionType="convolution",\
                                      beamWidthArray=kernelWidth)

The Gridding and Convolution projection tasks use a similar algorithm, and will produce the same results for a fully sampled mapping observation, if the beam width when using the Convolution task is set to 0.3 times the value used for the Gridding task. For intermediate sampled maps, the Convolution task can be set to have a relatively large kernel radius, so the resulting cubes do not contain any "holes". In contrast, the Gridding task has more stringent limits on the maximum size of the convolution kernel, which is not sufficiently large enough to populate all spaxels with at least one spectrum and results in "holes" in the cube. Therefore the Gridding task should not be used for intermediate sampled maps. The Gridding projection task is a wrapper for the task used for HIFI spectral maps, and so running the Gridding projection requires a HIPE installation that contains the HIFI software (e.g., selecting "all instruments" when installing HIPE). The task can then be run using the spireProjection task as:

cube = spireProjection(spc=preCube, wcs=wcs, projectionType="gridding")

A comparison of the results obtained for the example Orion Bar observation, using the Nearest Neighbour, Naive, Convolution and Gridding projection algorithms, is shown in Figure 7.61.

SSW cubes of the example Orion Bar observation. From left-to-right, these were created using the Nearest Neighbour, Naive, Convolution and Gridding Projection tasks. The corners are filled with adjacent values when using the Nearest Neighbour task, but the noise levels in the spaxels are also higher as there is no averaging. There are NaN spaxels within the map for the Naive projection, but no holes when a convolution is applied.

Figure 7.61. SSW cubes of the example Orion Bar observation. From left-to-right, these were created using the Nearest Neighbour, Naive, Convolution and Gridding Projection tasks. The corners are filled with adjacent values when using the Nearest Neighbour task, but the noise levels in the spaxels are also higher as there is no averaging. There are NaN spaxels within the map for the Naive projection, but no holes when a convolution is applied.


The four projection algorithms provide different ancillary fields in the resulting spectral cubes. Nearest Neighbour projection returns a cube with flux, error and flag. Naive and Convolution projections return a cube with flux, error, coverage and flag. Gridding projection returns a cube with flux, error and flag. The coverage for Naive and Convolution projections is described in Section 7.8.6.

7.8.6. Holes in the map: examining the coverage

The Naive projection and Convolution projection tasks provide the coverage. For any given detector, the standard pipeline product is the average of all forwards and reverse scans, with the number of scans recorded in the "numScan" column. For the Naive projection, the coverage is the total number of scans falling within a spaxel, i.e. the sum of the "numScan" column for all spectra within a spaxel. The minimum number of repetitions an FTS observation was allowed was two, and there are one forwards and one reverse scan per repetition, so unless a scan has been removed during processing, the minimum coverage for Naive cubes is four. In the case of the Convolution projection task, the coverage is convolved by the kernel in the same way as for the signal, and so the weighted contribution made by all scans within the kernel area are combined. The coverage is conserved so that the sum of the coverage cube should be the same for both the Naive and Convolution projection results. The default minimum coverage for CP cubes is 0.1. However this limit is not per spaxel, so spectra containing gaps can be present towards the grid edges of CP cubes.

The coverage can be visualised by opening a cube with the Spectrum Explorer and selecting the "Cov" field in the drop-down menu to the bottom right, as shown in Figure 7.62. It is likely the cut levels will need to be adjusted, which is provided as an option when right-clicking on the cube image. The coverage cubes in Figure 7.62 are both cut at 90%. The coverage information could be used for statistical analysis, or to adjust the map pixel (grid) size such that the coverage goes up or down.

The coverage of the Naive projected (naive) and Convolution projected (cp) SSW cube of the example Orion Bar observation. Each spaxel contains data from 0 (black), or 4 (orange) to 12 (white) spectral scans.

Figure 7.62. The coverage of the Naive projected (naive) and Convolution projected (cp) SSW cube of the example Orion Bar observation. Each spaxel contains data from 0 (black), or 4 (orange) to 12 (white) spectral scans.


Increasing the map pixel size can avoid creating holes in the Naive map (i.e. map pixels which do not contain any data). The pixel size can be increased by specifying a different grid spacing in the mapping user pipeline script. The default grid size for fully sampled maps is 9.5'' for SSW and 17.5'' for SLW. Figure 7.62 of the coverage map for the example Orion Bar observation, shows those pixels not containing any data points (as black) for SSW with this pixel size. If the standard grid was modified to have 12.5'' pixels, for example, the holes in the SSW map would disappear. Similarly the SLW pixel size can be reduced slightly without introducing holes.

7.8.7. Maps with faint continuum levels

When a faint source has been observed in mapping mode, uncertainties from the telescope model can affect the continuum shape in the same way as for a single pointed observation of a faint source (see Section 7.5). In such cases, it may be possible to reduce the residual emission by subtracting an appropriate dark sky spectrum from each spaxel in the cube. There are several things to consider if attempting this:

  • The dark observation used should be at least as long as the mapping observation to minimise added noise. It should also be close in time (and/or taken under similar observing conditions).

  • Each spaxel may already contain spectra from several different detectors, so subtracting a single dark spectrum is unlikely to improve small-scale noise, as this changes for different detectors.

  • It may be best to smooth the dark spectrum before subtraction, or to combine several detectors in the dark sky observation to smear out detector dependent effects.

  • If there are problems with small-scale noise, it may be better to subtract the dark detector-by-detector before gridding.

The following script provides one way to subtract a single dark sky spectrum from a cube. Note that the dark and cube should be processed with the same version of HIPE:

# Load the Observation Context
obs  = getObservation(obsid, poolName)
# Extract the SSW cube
sswCube = obs.level2.getProduct("HR_SSW_cube")
# Extract the dark sky extended-source calibrated product
# From a sparse observation
darkObs  = getObservation(darkObsids, poolName)
darkSpec = darkObs.level2.getProduct("HR_spectrum_ext")
# Subtract the dark SSWD4 spectrum from the SSW cube
subtractedCube = subtract(ds1=sswCube, ds2=darkSpec['0000']['SSWD4'])