PACS. Considerations for PACS Mapping. Herschel. PACS Mapping Page 1. Babar Ali,David Frayer,Pierre Chanial

Transcription

1 PACS Mapping Page 1 Considerations for PACS Mapping Babar Ali,David Frayer,Pierre Chanial

2 PACS Mapping Page 2 Req. I Mapping considerations for PACS data reduction pipelines I - A. History Version Date Author(s) Change description Sep 11 B. Ali, D. Frayer, P. Chanial First issue I - B. Summary The mapping mode of the PACS instrument is expected to be one of the most widely used AOT of the PACS photometer. Thus, accurate mapping software is essential for reaping the most science out of the scan map observations. MADmap, Mopex and Projection are three software packages that are being considered for reducing PACS mapping data into single map of the sky. The SPIRE instrument has already considered MADmap, Mopex and 4 other software routines and settled on using the MADmap routine for the SPIRE pipeline. This report presents a discussion of MADmap for reducing PACS data. The input PACS data is obtained from the PACS instrument simulator. I - C. Data Reference Sheet Ref Date Filename Comment Star-Formation simulation 14-August-2007 scan nf1 blue 001.fits Normal Factor 1 Star-Formation simulation 14-August-2007 scan nf100 blue 001.fits Normal Factor 100 SWIRE Field simulation 31-July-2007 scan45 blue 001.fits Scan at 45deg SWIRE Field simulation 31-July-2007 scan135 blue 001.fits Scan at 135deg I - D. PACS data simulations The PACS simulations are provided by the currently available PACS instrument simulator (see RD-2). The simulations are for the scan-map AOT with and without cross-scan. While the current implementation of HSpot does not allow for automatic cross-scanning (ie a second scan at scan angle orthogonal to the first one), it is possible to perform cross-scan via concatenated AORs. In order to keep the focus on the mapping and not on the reduction, we opted to make the simulations as close to ideal as necessary. This means that only the following noise sources were considered: (i) photon noise, which is dominated by telescope background. (ii) 1/f-ish noise, which is coded as a random walk algorithm. (iii) Inter-module gaps of 1-pixel. (iv) And, dead detector pixels. Transients, glitches, detector response, distortions and flat-field effects were turned off during the simulation. Some post-processing of the simulations was necessary due to two bugs in the current version of the simulator. We had to perform a mirror-flip of individual images. This bug was accidentally introduced in the latest version of the simulator. And, for the star-formation simulations, we used a slightly old version of the calibration file which produces a flat-field like effect that had to be removed prior to mosaicking. The simulator data also does not include correlated noise. There is some evidence that such noise does exist in the PACS data. For SPIRE, these correlations are removed prior to MADmap handling of the data. We can, for the time being, also assume that correlated noised is handled upstream in the pipeline process. Correlated noise will likely not affect the final output of the map; rather it will likely affect the noise estimates associated with the final map.

3 PACS Mapping Page 3 I - D.1. Starforming regions This field is taken from the Spitzer 24-µm survey of the Perseus region (see the Figure below). The field contains point sources, small (compared to PACS fov) and large scale structure. In addition, a roughly square calibration region is introduced to allow us to flux calibrate the simulator data. The value of the region is set to roughly 1 MJy/sr in the image. We performed two simulations: (1) with the input sky as it appears (nf1), and (2) with the input sky multiplied by a a factor 100 (nf100). The calibration square values were thus 1 MJy/sr and 100 MJy/sr, respectively, in the output of the two simulations. The two simulations are used for calibration (see below) as well as to provide two different regimes of surface brightness values. The nf1 data simulates a faint ( 30 MJy/sr) field, while the nf100 data simulates a bright field. The intent here is to explore how well the mapping software is able to remove the 1/f noise when either faint or bright flux levels are present. Ultimately, with several such simulations, it may also be possible to determine a cut-off flux/surface brightness level beyond which 1/f noise may be considered irrelevant. The calibration squares allow us to convert the output of the simulator, which is in volts, to MJy/sr as follows: sf = 99MJy/sr (< nf100 > < nf1 >) Where, sf is the scale factor in units of (MJy/sr)/(volts), 99 MJy/sr is the difference between the surface brightness of the two calibration squares, and < nf1 >, < nf100 > refer to the mean values (volts) measured for the calibration squares in the simulator output. Figure 1: The input sky used for star-formation simulation. The data are Spitzer 24 µm image of the Perseus region. The dark square is used for calibration (see text). I - D.2. Deep Extragalactic Field The publicly available Spitzer-24µm SWIRE image of CDF-South was used as the input truth image for the extragalactic test field (Fig.2). This field is much larger than the GOODS fields, and the SWIRE 24µm data are sufficiently deep for comparison with PACS. The background-subtracted 24µm image was scaled by a factor of 150, and then a constant background level of 5 MJy/sr was added to the field to represent the truth image for PACS-100µm. Since the MIPS-24 and PACS-100µm resolutions are similar, no PSF corrections were made. The scale factor of 150 is about 5-10 times larger than the expected average S100/S24 flux density ratio for

4 PACS Mapping Page 4 galaxies in the field. This large scale factor was used to yield a sufficient number of sources with flux densities of order of 100 mjy for accurate photometry measurements. The real sky for PACS-100µm is not expected to be as rich at the depth presented here. SCANLINE was used to simulate two PACS medium-rate scan AORs. Each AOR covers the central field with 12 legs using cross-scan steps of 145, which roughly matches the HSPOT uniform coverage parameters. One AOR was done at a scan angle of 45deg, while the second AOR was taken at an orthogonal angle of 135deg. This is effectively the largest simulation currently possible on computers with 2GB of memory, given a bug in the PACS simulator which prevents the successful chunking of the data into smaller groups. The SCANLINE config files were run through the PACS simulator jar-file. All sources of noise were turned on, but distortions, glitches, and flat-fielding effects were left off. The resulting image planes were flat with large rms values due to the telescope background and the 1/f noise drifts. The simulator data were calibrated using test input frames at different backgrounds. The conversion factor between the simulator output and surface brightness units of MJy/sr is MJy/sr per simulator-unit. The simulated data were combined with MOPEX and MADmap. The current PACS MADmap implementation does not yet make quality sub-sampled images. For comparison with MOPEX, we used the default pixel scale of 3.2 (better fidelity images can be made with sub-pixel sampling using MOPEX). In addition, MADmap currently only interpolates data to the nearest sky pixel. To test the MADmap interpolation scheme, we used MOPEX with GRID interpolation which also interpolates to the nearest pixel. MOPEX-GRID interpolation ( easy MOPEX) is about 10 times faster than the full MOPEX calculation. To test MADmap s ability to remove drift noise, we filtered the simulated data offline with a median time filter (filter widow of 9 s [3, scanning at 20 per sec.]) before combining the data with MOPEX. Figure 2: Input SWIRE 24µm image of CDF-South. The diameter of the circle is 30 arcmin. I - E. Mapping software and PACS pipeline implementation I - E.1. MADmap MADmap is one of the set of modules and utilities that are needed to step through raw Time Ordered Data (TOD) and produce a map. MADmap is the routine that produces the final sky map. Collectively the entire set

5 PACS Mapping Page 5 of these modules is referred to as MADCAP (Microwave Anisotropy Dataset Computational Analysis Package) and includes two other major modules: MADnes and MADspec. MADmap relies on the output of MADnes, an iterative time-stream noise estimation code written by Radek Stomper (LBL), for a critical input: the inverse time-time noise correlation matrix (invtt). MADspec is not relevant for PACS purposes and is not discussed here. The developers of MADCAP maintain two web pages where the reader can find more background on MADCAP and MADmap: cmc/madmap/doc/index.html borrill/cmb/madcap/ In addition, the reader is referred to RD-1, the SPIRE report on mapping algorithm comparison for a description of the MADmap software and algorithm. MADmap produces two types of sky maps: Naive Map In the so-called Naive map, MADmap simply takes the entire data cube and averages it. In the absence of 1/f noise, this kind of map may be considered a final map. The naive map also serves as the first guess for the signal for subsequent iterative analysis. Map For lack of better words, we will use map to describe the output of full MADmap code which tries to account for the 1/f noise and produce a final map of the sky using the full power of MADCAP. To produce such a map several iterations are needed. These are discussed below. I - E.1.1. Status of MADmap and its implementation in SPIRE pipeline MADmap is originally written by Christopher Cantalupo. This version of the code is sometimes referred to as the old MADmap since a newer version (not available to date), that parallelizes the code further is in the works. Pierre Chanial (Imperial College, one of the authors of this report) modified the old MADmap to allow for gcc compilation as well as to homogenize the TOD files between MADmap and MADnes routines. The modified old version is the one under consideration for instruments, and except where stated explicitly, the term MADmap refers to said modified old version of the code throughout this document. The SPIRE report (RD-1) identified MADmap as the likely candidate for SPIRE mapping. To comply with HCSS requirements, the code is being translated into Java at Imperial College. At the time of the writing, MADmap is mostly translated and expected to have the first version ready by the end of September, MADnes routines are expected to be available in Java in Spring 2008 (but an initial version may possibly be available as early as December 2007 to the co-authors of this report). The java MADmap will be a standalone product and in operation will be identical to the C- version. For the pipeline a separate I/O module (STATUS TBD) must be made available that will create TOD and inverse time-time noise correlation matrix (invntt) files in native MADmap format. The MADmap code depends on two main external libraries: MPICH and FFTW. For the SPIRE pipeline the MPICH dependency was removed, and an internal HCSS FFT routine is used for Fourier analysis. The MPICH routines allow parallel processing.

6 PACS Mapping Page 6 Given that there was no requirement on parallel processing, this dependency was removed during the translation process. C-developers take NOTE: MADmap only works with FFTW version 2.x and NOT with version 3.x or later. Within the SPIRE pipeline, MADmap will be used not only to create the Level 2.0 map product but also to remove the 1/f noise. It is perhaps important to point out that further up-stream in the downlink process a separate module is planned that will remove correlated 1/f noise. This is done by taking the drift from the so-called blind pixels and removing it from all active SPIRE pixels. As mentioned earlier, the MADnes part of MADCAP routines are not available in java. This module provides the critical inverse time-time noise correlation matrix essentially the noise properties of the detectors. In the current implementation by SPIRE the output of MADnes is treated as a calibration product within the pipeline. The generation of this calibration product is, therefore, currently done outside of the HCSS/DP environment. When MADnes routines are available in java, this generation will also occur within DP. It is not clear at this point how often this calibration product will require regeneration. We polled two local bolometer experts on this particular issue and have been advised that the best practice is to produce a noise map for each map. However, it is likely that the stability of the detectors and how they are used will determine how often to generate the invtt calibration file. I - E.1.2. Running MADmap on PACS data We briefly describe the data flow and wrappers used for mapping PACS data. A set of IDL wrapper routines, modified from similarly existing routines for SPIRE, are used to pass the data to MADnes and MADmap modules. These routines take as input the output of the Simulator with two post-processing steps (see below). The wrapper routines convert Individual PACS frames to the TOD files as needed by MADCAP and also pixelize detector readouts with its corresponding sky pixel(s). As is the case for SPIRE, we treated the noise matrix as a calibration product and generate this product prior to running the mapping code. Figure 3 shows the overall flow of data via the wrappers through the MADCAP modules. There are three calibration steps that require further explanation: Simulations and post-processing This is purely an artifact of the current simulator code and is discussed below. Pixel-to-Pixel Spatial Offset Image This file is used in the wrappers prior to running MADmap to relate the detector pixel to a pixel on the sky (final map). The implementation used here, by using an offset description from the image center, is quite flexible in that it can accommodate inter-module gaps as well as distortions. At the moment, the offset is simply an analytical relation; however, it can quite easily be extended to an actual image file containing the offset of the pixel center from the reference location. Noise Matrix This is the inverse time-time noise correlation matrix. It is one of the files needed by MADmap to estimate the uncertainties associated with 1/f noise. This particular file describes how data separated by a given time are related to each other. For example, the correlation is particular strong when the data are separated by only a few readouts (i.e. on time scales much smaller than where effects of 1/f noise become significant).

7 PACS Mapping Page 7 I - E.2. Mopex The reader is referred to the Spitzer Science Center website and RD-1, the SPIRE report on mapping algorithm comparison for a description of the MADmap software and algorithm. The web site address is: Figure 4 shows the high-level processing steps involved in using mopex. These are also described below. Simulations and post-processing This is purely an artifact of the current simulator code and is discussed below. FITS file generation Mopex uses FITS files for all of its data input/output. For the current analysis, we converted the data cube from the simulation in individual FITS files as part of the simulation postprocessing. Name List file This text file sets the mopex parameters and the steps to perform within the mopex environment. Pmask file This is a FITS file that describes which pixels are permanently damaged and should be ignored. Inter-module gaps for PACS are handled by defining an additional pixel within this Pmask file and marked it as permanently dead. As with MADmap, mopex requires a wrapper script (currently written in IDL code) to parse the input PACS data cube into the individual FITS format files for mopex. I - E.3. Projection At the time of the writing of this report we were unable to provide sufficient results from the Projection algorithm. We plan to provide these results in the next version. We also expect the code to be similar to in performance to Mopex with two main differences: (i) it is written in Java, and (ii) the code does not allow for surface brightness to be conserved, but does allow for flux to be conserved. I - E.4. MADmap iterations The MADmap and similar software are iterative by design since they must determine two unknowns (noise and signal) from the same set of data. While a unique solution is possible, since for each given sky pixel several independent measurements are available, in practice, it is difficult for modern computers to invert the problem directly and relay on iterative methods to make a guess at the signal and subtract it during each iteration to determine the noise. In subsequent iteration, this guess is improved as convergence is achieved. In fact, there are two types of iterations: A so-called outer iteration: This is the process by which signal is removed during each iteration to allow a better estimate of noise, and subsequently a better estimate of signal until convergence is achieved. A so-called inner iteration: This is the actual process of inverting the final map matrix. The map matrix is the set of linear equations describing the measured signal and noise (see the MADmap documentation)

8 PACS Mapping Page 8 for each sky pixel. gradient method. This set of linear equation is solved in MADmap via a preconditioned conjugate In practical terms (and in the SPIRE implementation) the noise matrix is generated independently using a suitable blank sky field; thus only one outer iteration needs to be performed. For the PACS data, a convergence tolerance of10 6 was defined for the inner iterations. For the simulations mentioned described here, this tolerance criterion required of order 150 inner iterations. I - E.5. Generating inverse time-time noise correlation matrix for PACS Any blank sky measurements obtained with PACS are suitable for this purpose. We used the simulations of the point-source (nearly a blank sky) to create the inverse time-time noise correlation matrix for PACS. This simulation had the least amount of signal present in the data and offered a more direct approach towards creating the noise matrix than the iterative methods. This noise matrix was used throughout the MADmap mapping. The linux version of the MADnes routines was used to create the noise matrix. I - E.6. Inter-module gaps and distortion A key consideration for PACS is the inter-module gap and the optical distortions present in the detectors. All mapping software discussed here can handle both type of these effects though the manner is different. I - E.6.1. MADmap In MADmap, the wrapper routines (currently available in IDL code) use an offset for each pixel to handle both the inter-module gaps and any distortions (not yet implemented). In summary, a offset (in right ascension and declination) is calculated and used for individual detector pixels assuming that the position of a reference pixel (or the center of the image) is known. This offset is then converted to a pixel position on the sky as a second offset from a fiducial position on the final sky map. Relevant to this discussion is how the pixel flux is distributed. This is described below. I - E.6.2. Mopex In Mopex a combination of post-processing and the Pmask calibration file is used to deal with inter-module gaps. An extra pixel is inserted in the data array and masked as dead to specify the gaps. The distortion correction is a bit more complicated since mopex uses the Spitzer distortion keywords, which are polynomial relationships. Given that PACS distortion is partially a result of module rotation, this is difficult to describe with keywords alone and will likely require that PACS data is separated into individual modules and then exported as FITS files. We have already attempted this with success albeit without real distortion. I - F. Results I - F.1. Faint star formation field The results from the simulation, nf1, the so-called faint star-formation field are shown in Figures 5 and 6. For comparison, the original input sky field is also shown. The figure captions identify which software package

9 PACS Mapping Page 9 was used to create the final image from the simulated data cube. Figure 7 shows the results for the bright star-formation field (similar to Figure 5). I - F.2. Deep Extragalactic Field The simulated data were combined with and without filtering using MOPEX for both the full MOPEX and MOPEX-GRID calculations. MADmap maps and MADmap naive (no corrections) maps were made for the combination of both AORs and for a single scan pass (one AOR) to demonstrate the usefulness of cross-scan data for MADmap processing (Fig.8). MADmap produced a small gradient across the field (increasing from E to W on the scale of 10 4 of the telescope background). I - F.2.1. Blank Field Sensitivity The noise (1σ) for each of the images in Fig.(8) was derived by fitting a Gaussian to the data distribution of the central image after iterative clipping of the data outside of the range from 2.5σ to +0.5σ (i.e., to avoid sources). Table 1 shows that the noise is about a factor of 10 larger without correcting for the time drifts (MOPEX no-filter, MADmap naive maps). We obtained about 30% lower noise values for the MOPEX filtered image than the MADmap image. A significant fraction of the sensitivity improvement is due to the more accurate interpolation scheme (MOPEX-GRID and MADmap yield similar results [both interpolate to the nearest pixel]). Table 1: Sensitivity Measurements Data Type RMS (1σ) [MJy/sr] (A) MADmap naive map of single pass (one AOR) (B) MADmap map of single pass (one AOR) (C) MADmap naive map with cross-scan (two AORs) (D) MADmap map with cross-scan (two AORs) (E) MOPEX with no-filter (two AORs) (F) MOPEX with filter (two AORs) (G) MOPEX-GRID with no-filter (two AORs) (H) MOPEX-GRID with filter (two AORs) Table Notes Sensitivity measurements of the central regions of the maps. All maps use the default pixel scale of 3.2. In comparison, HSPOT predicts a sensitivity of 8.2 MJy/sr for the effective average integration time of 13 s (two medium-rate scan AORs). I - F.2.2. Point Source Photometry Source lists were derived using the SSC MOPEX-APEX software. We derived our own truth catalog from the input PACS-100µm image. Catalogs from the simulator results were bandmerged using the IRAF-tmatch routine for comparison with the input truth list. Catalog matching was done with a 4 search radius after removing the systematic pointing offset of 2.4 introduced by the simulator. Figure (9a) shows the offsets of the positions of sources after removing the absolute pointing offset. The random offsets are a combination of the fitting uncertainties and the pointing jitter provided by the simulator.

10 PACS Mapping Page 10 APEX does both aperture and point-source fitting (PRF) photometry. For faint sources in crowded fields, pointsource fitting methods work significantly better than aperture photometry. Figure (9b) shows a comparison between PRF and aperture photometry, demonstrating the advantage of point-source fitting with these data. We adopted APEX PRF fitting for this report. A PRF from each image was made for source extraction. Sources were detected and extracted above the 3σ level for the MOPEX, MOPEX-GRID, and MADmap images (all maps with default 3.2 pixel scale). We extracted and matched 1285, 1214, and 1046 sources for the MOPEX, MOPEX-GRID, and MADmap images respectively. The smaller number of detected sources by MADmap may be due to the slightly smeared PRF for the MADmap image (Table 2). We quantified the photometric accuracy of MOPEX and MADmap by comparison to the truth catalog. For flux density bins ranging from 20 mjy to 500 mjy, we measured the fractional error given by the standarddeviation of the Observed/T ruth flux density ratio. Figure 10(a) shows the fractional photometric errors as a function of flux density. At low flux densities, the scatter of the MADmap measurements increase significantly. Similar photometric repeatability results were derived for both the MOPEX and MOPEX-GRID techniques. Figure 10(b) shows the average values of the Observed/T ruth flux density ratio as a function of flux density. The average values increase at the low flux densities due to the flux-boosting effect at lower S/N (i.e., systematically measure higher observed values at lower S/N). This effect is largest for the MADmap results. In addition, the MADmap photometric results required a systematic correction of 20% across all flux density bins to obtain agreement with the truth catalog and the MOPEX results. The exact cause of this photometric offset is currently not known. I - F.2.3. Point Source Image Fidelity We measured the sizes of the PRFs derived from the images to test the spatial precision of combining the data with MOPEX and MADmap. The PRFs were made by stacking isolated bright sources (> 100 mjy) within the images using the APEX prf estimate routine. Table 2 shows the FWHM measurements for the input, MOPEX, and MADmap images. The PRF for the MADmap image is smeared slightly in the East-West direction (Fig.11). Improved spatial resolution was obtained with MOPEX using sub-pixel sampling. Telescope jitter limits the ability to recover the full resolution of the input image. Table 2: Point-Source FWHM Measurements Data Type FWHM [arcsec] Input Image with 1.2 pixels ± 0.2 MOPEX with 1.2 pixels ± 0.2 MOPEX with 3.2 pixels ± 0.3 MOPEX-GRID with 3.2 pixels 7.8 ± 0.3 MADmap with 3.2 pixels ± 0.4 Table Notes FWHM measurements made by fitting a radial profile to the PRFs for each image. I - G. Discussion I - G.1. Noise analysis of the Star-Formation Field One quantitative measure of how well the mapping software performed in removing the 1/f noise is to consider how the calibration fields fared in the final maps. Recall that the calibration fields are artificially set to exactly 1 MJy/sr and 100 MJy/sr values in the faint and bright fields, respectively. A measure of the 1 σ values in the resulting maps directly compares the noise from all the components considered in the simulation (see above).

11 PACS Mapping Page 11 First, the simulator output is calibrated as described above from the output in Volts to MJy/sr. These are listed below. Code Median(nf1) Median(nf100) sf (Volts) (Volts) (MJy/sr)/(Volts) MADmap Mopex After calibration, the rms is measured in a rectangle aperture placed within the calibration field. For comparison, we obtained the expected noise from HSpot by coding the simulation as an AOR. Since HSpot currently does not provide a cross-scan mode, we used a repetition factor of 2 to provide the double coverage which would result from a cross-scan of the same region. The results are presented below. Field 1-σ rms (MJy/sr) MADmap Mopex HSpot Prediction nf1 field nf100 field Both visual inspection and the quantitative results presented here suggest that the clear winner in terms of removing the 1/f noise structure is MADmap. However, note that mopex results show similar rms values when a high-pass filter is applied to the time-stream. Such a high-pass filter is in appropriate for the data set considered here and these results are not shown (see point-source photometry below). This discussion, however, does not include photometric accuracy. The deep extra-galactic fields are used for that purpose (section TBW). We note in Figure 7 that for the bright point source present in the field, MADmap reduction leaves the so-called ringing offsets around the point source. The deep extra-galactic simulations will attempt to answer whether this has any effect on subsequent photometry. I - G.2. Sky pixelization One essentially free parameter to consider for all mapping software is the pixel size of the final sky map. And, related to this parameter is the question of how each of the mapping software handles distribution of the individual detector pixels to pixels on the sky. We elaborate on the latter first. Figure 12 shows a schematic view of the relationship between detector and sky pixels. In its current implementation, MADmap will allocate all of the flux of the detector pixel to the sky pixel which is coincident with the center of the detector pixel (dark hued pixel in Figure 12). The mopex software on the other hand can do one of two things: (i) it can repeat what MADmap does, and (ii) it conserves surface brightness by apportioning partial fluxes from the detector pixel to each overlapping sky pixel. The fractional overlapped area is used to determine the apportioning. A case for MADmap and mopex hybrid approach. While the MADmap code will allocate all of the flux of the detector pixel to one sky pixel (see above) it is possible to rearrange the TOD such that it works similar to what mopex does and give fractional flux to sky pixels based on overlap. The data are arranged within TOD files as: number pixel signal weight. The pixel is the sky pixel, signal is the detector readout and weight is set to

12 PACS Mapping Page in the current implementation. number tells MADmap how many pixel-signal-weight blocks to expect. In a hybrid approach, one can use weight as the appropriate ratio factor for the detector signal and distribute it over several sky pixels. In this case, number will not be 1 and weight will not be 1.0; rather the total weights will add up to 1.0 to preserve the surface brightness. What this approach will require will be to create a fiducial sky image (a la mopex) to first figure out the weights and which sky pixels overlap the detector pixel. The mopex code can, in theory, serve this purpose. However, note that this will increase the running time several fold. We note in our experimentation that when the sky pixels are chosen to be much smaller than the original detector pixels, MADmap, in particular, will have insufficient detector pixel (centers of) overlap between adjacent sky pixels. The result will be missing regions where no detector pixel overlaps were found. This is illustrated in Figure 13. I - H. Conclusions We have successfully used the SPIRE JAVA implementation of MADmap to process PACS simulator data. To incorporate MADmap into the PACS DP, the appropriate I/O interface routines would need to be developed. MADmap does an excellent job of removing 1/f noise and recovering extended structures of bright regions. For deep fields of faint point sources, a simple time filter with MOPEX yields better results than those currently obtainable with MADmap. The scatter of the MADmap photometric results increases significantly at faint levels in comparison to MOPEX, which may reflect, in part, the slightly distorted PRF derived from the MADmap image. Improved results with MADmap may be possible with sub-pixel sampling.

13 PACS Mapping Page 13 Time Simulation 1 Simulation 2 Data cubes Simulation post-processing Generate TODs MADnes Calibration Object Pixel-to-Pixel Spatial Offset Image Calibration Object Noise Matrix MADmap Naive Map Sky Map Coverage Map Figure 3: Schematic showing the very high-level flow of data through MADCAP to generate the final sky map.

14 PACS Mapping Page 14 Time Simulation 1 Simulation 2 Data cubes Simulation post-processing FITS files Calibration Object Name List file Mopex Calibration Object PMask File Sky Map Coverage Map Figure 4: Schematic showing the very high-level flow of data through Mopex to generate the final sky map.

15 PACS PACS Mapping Document: Date: Version: PICC-NHSC-TN Sep Page 15 Mopex MADmap MADmap Naive Figure 5: The final sky maps for the faint star-formation field. The input sky is shown for comparison at the top left. The mopex results are shown at the top right. The naive map from MADmap is shown at the bottom left and the full MADmap map is shown at the bottom right. The mopex and MADmap naive maps are both dominated by the 1/f noise, which led to the obvious striping feature. The full MADmap sky image is able to handle the 1/f noise.

16 PACS Mapping Page 16 Figure 6: A detailed view of the faint star-formation field comparison. The image on the left is a cut-out from the Figure 5 showing the region near the calibration field in the mopex reduction. The image on the right is similarly taken from the MADmap reduction. The 1/f noise clearly dominates in this flux region; however, MADmap reduction accounts for the 1/f noise reasonable well(see discussion).

17 PACS PACS Mapping Document: Date: Version: PICC-NHSC-TN Sep Page 17 Mopex MADmap Naive Figure 7: The final sky maps for the bright star-formation field. The input sky is shown for comparison at the top left. The mopex results are shown at the top right. The naive map from MADmap is shown at the bottom left and the full MADmap map is shown at the bottom right. The mopex and MADmap naive maps are both dominated by the 1/f noise, which led to the obvious striping feature. The full MADmap sky image is able to handle the 1/f noise. MADmap

18 PACS Mapping Page 18 Figure 8: Maps of the simulated PACS-100µm extragalactic CDF-South field. (A) MADmap naive map of single pass; (B) MADmap map of single pass; (C) MADmap naive map with cross-scan; (D) MADmap map with cross-scan; (E) MOPEX with no-filter; (F) MOPEX with filter; (G) MOPEX-GRID with no-filter; (H) MOPEX-GRID with filter. The maps are for two AORs except for (A) and (B) which represent one AOR (single pass).

19 PACS Mapping Page 19 Figure 9: (Left [a]) Positional offsets between the input truth catalog and the output positions after removing the absolute pointing offset. (Right [b]) Comparison of aperture (black square) and PRF (grey diamond) point-source photometry with APEX. Figure 10: (Left [a]) Fractional error as defined by the scatter of the Observed/T ruth flux density ratios. (Right [b]) Average ratio of Observed/T ruth flux densities shown as solid lines with the 1σ dispersion of the ratio shown as dotted lines. The average MADmap values have been corrected for a 20% systematic photometric offset for comparison with MOPEX-GRID.

20 PACS Mapping Page 20 Figure 11: PRF images from the simulated PACS-100µm extragalactic CDF-South field. (A) MADmap image with 3.2 pixels; (B) MOPEX-GRID image with 3.2 pixels; (C) MOPEX image with 3.2 pixels; and (D) MOPEX image with 1.2 pixels. In each case, the PRF is sampled at 4 with respect to the input image pixels.

21 PACS Mapping Page 21 Final sky-map grid Detector pixel Sky pixel co-incident with center of detector pixel (in dark hue) Center of detector pixel (black circle) Figure 12: Schematic showing the relationship between pixelization on the final sky map and an individual detector pixel.

22 PACS Mapping Page 22 Figure 13: This figure shows the results of oversampling the sky with the detector pixels. The figure on the left is a MADmap sky image and the one on the right is the same reduction except the pixelization on the sky is increased by a factor of 3. There are clearly regions on the sky for which no detector pixels overlaps are available.