ip.diffim.generateAlardLuptonBasisList INFO: PSF sigmas are not available Log Message when generating templates

Support
#1

When we generate coadded templates, I am seeing the following entry in the output log. ip.diffim.generateAlardLuptonBasisList INFO: PSF sigmas are not available or scaling by fwhm disabled, falling back to config values

We generate these coadds starting with Raw data, processing up through the calexp stage, then generating templates with the following yaml that we name coadd.yaml

description: The AP template building pipeline specialized for DECam
# This pipeline assumes the working repo has raws, calibs, refcats, and a skymap.
# An example of running it:
  # pipetask run -j 4
  #              -b REPO
  #              -d "exposure IN (289409, 289697, 288935)"
  #              -i DECam/raw/all,DECam/calib,DECam/calib/DM-26971,refcats/gen2,skymaps
  #              -o DECam/templates/test1
  #              -p APTemplate.yaml --register-dataset-types
instrument: lsst.obs.decam.DarkEnergyCamera
tasks:
  makeWarp:
    class: lsst.pipe.tasks.makeCoaddTempExp.MakeWarpTask
    config:
      makePsfMatched: true
      doWriteEmptyWarps: true
  assembleCoadd:
    class: lsst.pipe.tasks.assembleCoadd.CompareWarpAssembleCoaddTask
    config:
      doInputMap: true

We call this yaml with pipetask run -j30 --register-dataset-types -b . -i skymaps,[calexp collection name] -o [template collection name] -p yamls/coadd.yaml

Is this an expected log message, or is something happening that we do not expect? A quick visual check of the calexp images does not reveal anything out of the ordinary.

#2

I took an initial look at Hayden’s question, and got as far as noticing MakeWarpTask uses ModelPsfMatchTask from ip_diffim, which is where the warning is coming from. I am not sure what happened during image processing to result in no PSF sigmas being available for making PSF-matched warps. Since PSF-matched warps are an important input for CompareWarpAssembleCoaddTask, I don’t think this warning should be ignored.

#3

The log message can be a bit misleading, but by default, a config variable scaleByFwhm is set to False (disabled) which is what you’re seeing there. It is expected and you can ignore it.