Requirements for overhauled calibration task?

Data Management
#61

Ah, okay. I was thinking we’d use Gaia for all of this since we get good star/galaxy separation from morphology (and, of course, great astrometry) for stars that should be bright and faint enough to serve as our “PSF stars”. Is there a reason that might not be the case?

Either way it’ll be good to have the capability to make our own list of PSF stars.

#62

We’ll certainly use Gaia stars, but I think we’ll probably want to go fainter.

#63

I updated CalibrateTask and DetectAndMeasureTask to handle catalog-based star selectors. It was a small change, though it requires a small RFC for adding a usesMatches method to StarSelector.

#64

@jbosch, @rowen I noticed this behaviour changed recently in the current ProcessCcdDecam.

In w_2015_40 when the astrometry.macther failed I had a RuntimeError

processCcdDecam.calibrate.astrometry.refObjLoader: Loaded 1420 reference objects
processCcdDecam.calibrate.astrometry.matcher: filterStars purged 0 reference stars, leaving 1420 stars
processCcdDecam.calibrate.astrometry.matcher: Purged 5 unusable sources, leaving 649 usable sources
processCcdDecam.calibrate.astrometry.matcher: Found 0 usable matches, of which 0 had good sources
processCcdDecam FATAL: Failed on dataId={‘visit’: 205484, ‘ccdnum’: 1}: Unable to match sources

File “/home/afausti/lsst/Linux64/meas_astrom/11.0-1-g60db491+6/python/lsst/meas/astrom/matchOptimisticB.py”, line 310, in matchObjectsToSources

raise RuntimeError("Unable to match sources")

RuntimeError: Unable to match sources

Now, using the latest tag w_2016_03, it continues with a WARNING

processCcdDecam.calibrate.astrometry.refObjLoader: Loaded 1420 reference objects
processCcdDecam.calibrate.astrometry.matcher: filterStars purged 0 reference stars, leaving 1420 stars
processCcdDecam.calibrate.astrometry.matcher: Purged 17 unusable sources, leaving 637 usable sources
processCcdDecam.calibrate WARNING: Unable to perform astrometry (Unable to match sources): attempting to proceed
processCcdDecam.calibrate WARNING: Failed to determine photometric zero-point: No matches available
processCcdDecam.detection: Detected 2645 positive sources to 5 sigma.
processCcdDecam.detection: Resubtracting the background after object detection
processCcdDecam.measurement: Measuring 2645 sources (2645 parents, 0 children)

For my tests it is more useful if it raises a RuntimeError and exits.

Is there a way to control this behaviour? what are the “require” configuration options?

#65

Hi,
@nidever help me to indentify the configuration options, they are:

config.calibrate.requirePhotoCal=True
config.calibrate.requireAstrometry=True

which I set to True. Thanks!

#66

I am now trying to identify all measurement algorithms needed. CharacterizeImageTask should make all measurements required to determine a PSF. What measurements are those? Beyond centroid, this seems to depend on which star selector and PSF determiner are used by MeasurePsfTask.

Star selector options include:

  • CatalogStarSelector: hard-coded to use PSF flux
  • ObjectSizeStarSelector: configurable; defaults to base_GaussianFlux_flux
  • PsfStarSelector: configurable, defaults to base_PsfFlux
  • SecondMomentStarSelector (the default, despite using PSF flux): which is hard-coded to use PSF flux
  • (SizeMagnitudeStarSelector: I’m not sure, but we doubt it works in any case)

PSF determiner options include:

  • PcaPsfDeterminer (the default): no additional measurements used
  • PsfexPsfDeterminer: uses prefs.getPhotfluxRkey(), but I have not found any preference files, so I’m not sure what values this usually takes

In any case, it looks to me as if CharacterizeImageTask must measure base_PsfFlux (despite the incongruity) and base_GaussianFlux_flux (in addition to a centroid, of course). Does anything else come to mind?

Another consideration is what users expect to find in the icSrc data product. We can add more measurement algorithms if there is a need for them.

#67

I think we want to run at least the following (there’s nothing else I can think of now, but that doesn’t mean this list is complete):

  • SdssCentroid: requires a Psf attached to the exposure, but we’ll have an initial guess one at least.
  • SdssShape: I expect this to be the primary input for most morphological star selectors.
  • PixelFlags: always need to run this.
  • GaussianFlux: we probably want something like a galaxy model flux, but we don’t want to run CModel until we have a pretty good Psf, as it’s slow. So someday, when we can configure later stages differently and actually use the Psf from the previous iteration, we’ll want to switch from GaussianFlux to CModel.
  • PsfFlux: like CModel, will only do a good job once we have a good Psf, but unlike CModel is fast enough to run regardless. And it seems to be bizarrely required by one of our StarSelectors (maybe file an issue on that?).
  • CircularApertureFlux: I can certainly imagine star selectors wanting a sequence of aperture fluxes, so even if the current set doesn’t need them, I think these are worth running (and they’re fast enough to not be a performance concern).

Also, the default StarSelector should be switched to ObjectSizeStarSelector, which was what we use on the HSC side. It’s received all the recent updates, as we’ve not really used SecondMomentStarSelector since it was introduced.

#68

@jbosch thank you very much. For the record, here are the default algorithms run by SingleFrameMeasurementTask:

  • base_PixelFlags
  • base_SdssCentroid
  • base_GaussianCentroid
  • base_NaiveCentroid
  • base_SdssShape
  • base_GaussianFlux
  • base_PsfFlux
  • base_CircularApertureFlux
  • base_ClassificationExtendedness
  • base_SkyCoord
  • base_Variance

Comparing this to your suggested list I see the following that are not on your list:

  • base_GaussianCentroid
  • base_NaiveCentroid
  • base_ClassificationExtendedness
  • base_SkyCoord
  • base_Variance

Of these, I would think base_ClassificationExtendedness might be of interest to star selectors (though I don’t think it is presently used). I’m not sure about the last two, but they look innocuous, as do the two extra measures of centroid. Unless any of these is particularly slow I wonder if I should not simply use the default set?

#69

ClassificationExtendedness is only as good as your Psf model, and even then it’s a fairly trivial combination of slot_ModelFlux and slot_PsfFlux that I’d guess any StarSelector that used it would want to re-do more carefully.

SkyCoord cannot be run unless we have a Wcs (and all it does is set the Coord fields from the slot centroid). I don’t think we need to run Variance at this stage, or the two other centroiders.

#70

@jbosch thank you. Do you happen to know the syntax for changing the values for a RegistryField that accepts multiple values? I’ve tried the following in CharacterizeImageConfig.setDefaults(self) and neither works:

self.detectAndMeasure.measurement.plugins[:] = ["base_PixelFlags",...]

self.detectAndMeasure.measurement.plugins = ["base_PixelFlags",...]
#71

I think you want .plugins.names = ....

It’s best to think of .plugins behaves like a dict, with a .names set-like object that controls which items in the dict are active. There may be some syntactic sugar that sometimes allows the .plugins to act like .plugins.names, but I think that may have always been a bad idea (I think I recall Martin and I disagreeing on the merits of that, but I don’t remember who was on which side).

#73

Thanks. At risk of asking too much, any thoughts on the difference between:

detectAndMeasure.measurement.value.plugins = ["base_SdssCentroid", ...]

and

detectAndMeasure.measurement.plugins.names = ["base_SdssCentroid", ...]

the former appears in a unit test I’m trying to debug and I have no idea what “value” is (it doesn’t show up in the task config), but it may be having the same affect as the latter.

#74

Definitely prefer the latter. I wouldn’t have expected the former to work, and I suspect the fact that it does is an accident of some other feature.

#75

Thanks. I guess “value” is returning some interesting object that is then being modified. It’s used a lot in that unit test, alas, e.g.: many lines such as:

....measurement.value.slots.shape = None

but just removing the value. seems to work, so I’ll do that.

#76

Excellent suggestion! That basically solved the problem I was having in CharacterizeImageTask with PSF iteration not converging (it still wanders around slightly, but not nearly as badly). I also added a config parameter that controls the iteration, to allow replacing the fit PSF with a simplified version at the start of each iteration or not.