# Verification Datasets Meeting 2016-01-27 Minutes **URL:** \ **Category:** Data Management\ **Tags:** verificationdataset\ **Created:** [January 28, 2016, 4:47pm UTC](https://www.rubin.community/t/verification-datasets-meeting-2016-01-27-minutes/506 "2016-01-28T16:47:49Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![nidever](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/nidever/32/29_2.png) [@nidever](https://www.rubin.community/u/nidever)\ **Post date:** [January 28, 2016, 4:47pm UTC](https://www.rubin.community/t/verification-datasets-meeting-2016-01-27-minutes/506/1 "2016-01-28T16:47:49Z")
Attending: David, Angelo, Frossie, Robert Lupton, Mario, Robert Gruendl, Hsin-Fang, Michael Wood-Vasey, Simon, Tim Axelrod, Colin Regrets: Dominique, Ciardi Notetakers: Colin, David **Angelo:** - Changing settings for matching when processing the bulge data. Was seeing [processCcd.py](http://processCcd.py) failures when the stack couldn’t match enough stars to the astrometric reference catalog. Default match distance was 3”, changed to 20”. - Robert: The offsets are larger on one side of the image compared to the other. Looks like the distortion terms are not quite correct, and the astrometric matcher is very dependent on those values. obs\_decam should be providing focal-plane-wide distortions, is it? - Simon: Distortion is defined in the camera mapper. - We aren’t sure if we have measured this, or if it has been included in obs\_decam. - Hsin-Fang might look at updated the distortions in the obs\_decam camera geometry/mapper. - Results are at : [https://confluence.lsstcorp.org/display/SQRE/Bulge+Survey+Processing](https://confluence.lsstcorp.org/display/SQRE/Bulge+Survey+Processing) **David:** - Processing COSMOS DECam data. - Showed a comparison of community pipeline-reported field-averaged ellipticities. Suggests this could be telescope related more than pipeline. - Robert Gruendl strongly suggests against using the CP-provided FWHM header value. They are not reliable. David will work on deriving our own values from the stack outputs. - David showed the number of cosmic rays per exposure between different filters. Some variance between filters. Will make versions with CRs per second since the exposure times change a lot. Will also look at number of pixels affected by CRs and inspect images to make sure they are real CRs. - Showed WCS RMS scatter vs different filters. The higher values in g/r/i bands is probably because they are deeper and the fainter stars have higher astrometric uncertainty. - Showed a CMD in g and i band (average values over multiple exposures in the same filter). Seeing up to 1 mag scatter between repeat single epoch observations of stars. Calibration against 2MASS J band without color terms. What is the right way to do this? You need a photometric calibration reference catalog that uses similar bands. If you don’ have that in the field of the observations then you can’t photometrically calibrate with the stack and you can’t coadd (image scaling for coadds depends on the photometric zero points). - In the near future there’l be a step between processCcd and coadd that will derive precise relative photometry, but doesn’t exist yet. - For COSMOS field David will use SDSS data for the reference catalog. Nothing available for the SMASH fields. - Results are at: [https://confluence.lsstcorp.org/display/SQRE/COSMOS+DECam+data+reduction](https://confluence.lsstcorp.org/display/SQRE/COSMOS+DECam+data+reduction) **Hsin-Fang:** - Bug, large shift in post-ISR product - Ran MWV astrometry check - relevant ticket: [https://jira.lsstcorp.org/browse/DM-4906](https://jira.lsstcorp.org/browse/DM-4906) **MWV:** - Working on photometric repeatability - Using some of Jim’s codes for matching and measuring repeatability - Talking to John/Frossie about what to do next **Simon:** - Russell finishing rewrite of processCcd, needs help running on data, making sure it covers all use cases can help with configs (need to be changed) - Volunteers, Hsin-Fang and David - It should work with skipping ISR, don’t need to use processCcdDecam (or similar for other imagers) anymore **Colin:** - Had to leave at the hour, but no major updates **Mario:** - Had to leave at the hour **Francisco/Yusra:** - Not on **Dominique:** - Couldn’t make the meeting today