IPAC 2MASS Working Group Meeting Minutes #60

IPAC 2MASS Working Group Meeting #60 Minutes, 5/09/95


T. Chester, T. Evans, J. Fowler, T. Jarrett, D. Kirkpatrick, G. Kopan, B. Light, C. Lonsdale, S. Wheeelock


  1. Review of Status and Plans for Processing of April '95 Data


No formal working group meetings were held since meeting no. 59 on April 4, because the only subject of concern was getting the pipeline software ready and working, and this was accomplished via many ad hoc splinter meetings.


  1. Review of Status and Plans for Processing of April '95 Data On March 23, R. Cutri published a plan for analyzing the data from the April '95 protocamera run. The purpose of this meeting was to review the status of the processing relative to this plan and to determine whether changes to the plan were needed. The key dates involved in the plan are as follows: Items A through C appear to have been accomplished, and item D was proceeding at a rate expected to supply about ten nights of good data. Item E was almost accomplished, with all but a few of the 145 scans of 95-04-25 having been run through the pipeline. This processing has shown that about 200 hours of processing time is needed per night of observation; with three CPUs running simultaneously, this implies that about three days are needed to process one night of observation. The 95-04-25 scans that have made it through the pipeline are sufficient for analysis to begin immediately, i.e., item F can begin right away.

    Analysis tasks are to be run on karloff, while lugosi handles the pipe- line operations. There are several different categories of analysis to be considered and prioritized. These are listed in R. Cutri's plan, and include primarily: (a.) flat-fielding and photometric-response issues; (b.) time- varying PSF issues; (c.) photometric calibration issues (such as stability, extinction and color terms in the photometric transformations); (d.) galaxy processing issues. Regarding (a.), the c#flat program, now officially named csflat in order to accomodate certain shortcomings of unix, has been deli- vered after successful testing on scan 026 of 95-04-21. The emphasis in the near term, however, will be on items (b.) and (c.). Regarding (b.), the plan involving Moffat-blurred real PSFs from 94-06-01 will be put on hold because of difficulties in getting kamphot PSFs from simulation data that look enough like the Moffat-blurred real PSFs to permit a correspondence to be set up. This correspondence is needed in order to tie in the enpixelated energy histogram information produced by G. Kopan's bumps program; i.e., the bumps output is the observable information that is intended to allow kamphot to select a PSF model to use. Without the correspondence between the Moffat- blurred PSFs and the kamphot PSFs produced in the same simulation runs as the bumps output, the connection between a seeing-dependent observable and the theoretical PSFs cannot be made. Instead we will concentrate on getting kamphot's own PSF estimation capability to work. This will require extra CPU time, but it will provide potentially useful experience.

    As part of the activity in item G of R. Cutri's plan, B. Light will pursue getting the kamphot PSF capability to work in time for item H, the June 1 start of production processing of the April '95 data. Items I and J are too far downstream to evaluate at this time, but they appear reasonable if the June 1 starting date is achieved.

    The working group agreed that the plan as they understood it did not include using csflat in the production runs, no matter how well it might appear to work in the analysis pipeline. The reason for this is that the cflat method, while known to be based partly on unjustified assumptions, produces results with very limited degradation, whereas the csflat method still depends on the stability of the photometric response or the frequent calibration of that response, and may involve pitfalls not yet discovered. Since the time-variable PSF and other calibration issues provide a full set of challenges by themselves, we will not plan to slip csflat into the production runs in addition.