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.