RFD discussion on initial PSF FWHM estimate, Dec. 15, 12:30pm PST

Data Management DM Notifications
#1

RFD discussion on initial PSF FWHM estimate, Dec. 15, 12:30pm PST

Currently, one of the configuration parameters is an initial estimate of the PSF FWHM (calibrate.initialPsf.fwhm). processCcd can fail if this is not set properly. This is problematic for two reasons:

  1. The LSST science pipeline needs to be completely automated and can’t depend on exposure-specific user input.
  2. The LSST config philosophy is that there is a one set configuration setup for a full (re)run of a dataset. If the initial PSF FWHM config parameter needs to change from visit to visit (because the seeing does change throughout the night), then this breaks our “one config only” philosophy.

Therefore, we need code that will automatically estimate the PSF FWHM. A few options on how to proceed have already been mentioned but no clear path has emerged. Therefore, we will have an RFD discussion on this topic. Note that this will impact how single frame processing (e.g., processCcd) works.

A couple of issues/ideas to keep in mind:

  • can we use an iterative procedure starting with a delta function and looping through most of the single frame processing steps a couple of times until we converge on a good PSF
  • the single-visit CR rejection algorithm requires an initial PSF estimate
  • how to deal with contamination from galaxies and “junk” which will mess up the PSF estimate
  • if we use an external catalog to select the stars then this will require more steps (i.e. astrometry, matching, etc.)

Product of the discussion:

  • We want to converge on the path forward on how to implement an automated initial PSF estimation code
  • Who will do the work, or which team
  • What is the priority
  • On what timescale should this work be completed

Coordinates:

  • RFD slot on Tuesday Dec. 15, 12:30pm PST
  • bluejeans: ls.st/jmc

See also: Outline of main processCcd.py algorithm

#2

I will not be able to attend (I’ll be at a conference in Davis), but I don’t think I’m critical for this discussion.

#3

Please note that the pipeline does NOT need an “initial estimate of the PSF FWHM”. What it needs is an initial PSF. That initial PSF does not have to be an estimate of the actual PSF, and therefore the two “problems” are not actually problems. As a demonstration of this, we are currently processing 5000 HSC exposures (of 104 CCDs each) with a single configuration, without relying on exposure-specific user input.

I fear that this has been misunderstood and blown all out of proportion. Certainly the initial bootstrap of the calibration can be improved, but it’s not the tremendous “problem” it’s been made out to be.

The initial PSF should be set to the narrowest PSF you believe you have in the data. The default value of 1 arcsec is probably not ideal, at least not for data from sites with good seeing. A simple configuration change can deal with all the apparent “problems”.

#4

Thanks for your comment, and maybe it’s not as big of a deal as I’m making it out to be. But processCcd DOES require an initial PSF FWHM (or “seeing”) in order to run, it’s in the configuration parameter “calibrate.initialPsf.fwhm”. If this is not set properly then visits can fail, which is a problem. That’s the issue I want to discuss this afternoon.

#5

In addition there is this note in calibrate.py on the need for an initial seeing guess for CRs.

It is moderately important to provide a decent initial guess for the seeing if you want to
deal with cosmic rays. If there’s a PSF in the exposure it’ll be used; failing that the
CalibrateConfig.initialPsf is consulted (although the pixel scale will be taken from the
WCS if available).

#6

Hi @nidever, @price – was there an RFD about this? What was the outcome?