# Verification Datasets Meeting 2016-07-13 Minutes **URL:** \ **Category:** Data Management\ **Tags:** verificationdataset\ **Created:** [July 13, 2016, 6:17pm UTC](https://www.rubin.community/t/verification-datasets-meeting-2016-07-13-minutes/930 "2016-07-13T18:17:03Z")\ **Posts on this page:** 2\ **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:** [July 13, 2016, 6:17pm UTC](https://www.rubin.community/t/verification-datasets-meeting-2016-07-13-minutes/930/1 "2016-07-13T18:17:03Z")
**Verification Datasets telecon** Attendees: Simon, David, MWV Regrets: Colin **Simon:** - trying to make a repository that is agnostic to camera - put files in repository and run processCcd on it (must have previously ISRed) - just need camera info for ISR - need to know variance pretty well otherwise CR rejection falls apart if background subtracted then you need to give the noise level (scalar) - just assumes a single 2D grid of flux values, no variance or mask plane, but could add that in - giving people the ability to use processCcd like SExtractor - it internally bulids the variance (using gain, config parameter) and mask plane can also set lower threshold for “good” values, also needs to know the noise level - uses repository, can use Butler to get the source catalog, etc. - could actually hide the butler by adding a little bit of code that checks if the file exists in the repository and if not then it adds it - currently a branch under SimonKrughoff obs\_file tickets/DM-6924 branch of both obs\_file and pipe\_tasks [c.l.o post](http://www.rubin.community/t/running-processfile-with-lsst-stack-v12-0/904/17) about this - probably useful for the collaborations **David:** - had meeting with PanSTARRS people at MPIA and discussed QA, mostly done after the fact to see what issues there are (forensic mode) - Simon, discussion of prompt processing, send out alerts on 99.9% of images that aren’t corrupted by any of the processing - image also needs to be scientifically useable, who makes this choice - maybe use OCS flags? - need red light/green light on Level 1 products - NCSA is putting up a verification cluster and they wanted to know what workflow people want, slurm and condor a possibility - SQuaRE doesn’t want to much effort on developing a new workflow system - David, want to run PSFEx on COSMOS to see if the PSF model and photometry is better - CR, problems on DECam COSMOS images, but SK ran some it found ~80% of the CRs - is CRblaster work better, CP uses it to identify and mask them should compare LSST to CRblaster - MWV suggested having a CI test to find a certain number of CRs in an image - issues with variance plane can cause problems with the CR software, was an issue with CP-processed DECam data in the past, wanted to double-check with LSST ISR but never quite got there **MWV:** - planning improvement for LDM-151 on SDQA - a lot of pieces in SDQA still need to be designed ---
**Author:** ![price](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/price/32/488_2.png) [@price](https://www.rubin.community/u/price)\ **Post date:** [July 13, 2016, 6:51pm UTC](https://www.rubin.community/t/verification-datasets-meeting-2016-07-13-minutes/930/2 "2016-07-13T18:51:57Z")
CRblaster uses the LACosmic algorithm, which is simply Laplacian edge detection. I believe our CR code does essentially the same thing. It may just need a front-end that correctly estimates the variance and PSF, and a bit of parameter tweaking (e.g., the background subtraction scale). I also found on HSC that setting `cond3_fac2=0.4` helps.