Populating the CCF

1. Populating the CCF • Immediate needs are driven by the requirement to test the SAS over the summer before public release. (A release called SAS-LH already in test but with an incomplete/incorrect CCF set - scientific validation of SAS could be hampered by CCF status) • Suggest we concentrate first on calibration components that affect the calibrated events list compilation (positions, gain, exposure corrections and bad pixels). DISCUSS • It is understood in the community that effective area files will evolve with improved understanding. We have only committed to release SAS and public data when a “10%” accurate calibration is available - it seems we are probably close to this already • The CCF files are produced via. a scripting process using the SAS tool “deceit”. Instrument etams should supply ASCII tables for SOC to ingest • Note that the SAS convention is for pixels counting from 1 not 0, so please supply co-ordinates in SAS convention OR AT LEAST BE EXPLICIT IN DELIVERY NOTE • Explicit time dependence is in the CCF files via a VALIDITY DATE . This will be necessary to cover changes in on-board configurations (bad pixels) CTI changes etc.. Need to ensure coherent updates SCI-SA

2. Current Status of CCF files • ADUCONv (aka gain) MOS updated to reflect lack of agreement in Internal Cal centroids. PN in MPE-supplied algorithm - needs to be maintained by SOC in long term. (intimately connected with RMF !) • CTI MOS based on simple pre-flight model (no significant change?). PN in MPE-supplied algorithm - needs to be maintained by SOC in long term - concern about speed of execution • Metrology Used Lockman Hole and NGC2516 (recently repeated). In principle ~1-2 arcsecs accuracy, but need to check carefully that the correct AHF files have been used (SIAM corrected?). Updates expected with catalogue cross-correlation • Timing While the absolute timing calibration awaits proper Orbit files, the relative timing and exposure correction for dead times should be completed so that this portion of effective area and map generation can be included. Present data based on commissioning phase SCI-SA

3. Current Status of CCF files (contd) • Bad pixels Aligned with on-board version. Low level (flickering?) pixels should be in CCF as well? Run badpixfind • Filter transmission Current data directly extracted from Orsay - known to be implausible values - reconcile with physical model (ACIS O-edge?) • Background Suggest we now have a tool to generate background where in-field data cannot be used. Blank field event lists with “high” and “low” level sets to be combined based on the DSCLN/NABOVE counters. But Spectral variation? • PSF Proper confirmation awaiting good dataset so that core and wings can be merged. Pile-up model can really be verified only when we have the baseline PSF? • Effective area Cannot treat mirror and EPIC separately except for Au edge or after cross-calibration with RGS SCI-SA

4. Current Status of CCF files (contd) • RMF MOS rather well-known from Orsay (?). PN updated from FS in-flight CAL data. Need to verify the SAS response generation is coherent with EPIC PI-produced data. Share the raw data files that go into these • Flat-field In addition to Orsay, build-up detector co-ordinates data from in-flight. However due to straylight there is in-field photon distribution (10%) from outside the field, which partially masks the vignetting function. The major CCD effects (edge pixels) can be extracted to rectangular region expressions • Optical Transmission Filters seem to perform better than in CCF. Not a science issue, but should be updated a.s.a.p. as it affects the filter choice for mission planning • Offset/variance Not a SAS issue as the data can be verified with E3/E4 values? Need to copy existing sets to CCF though • OUTSTANDING DATA THAT WE NOW KNOW NEEDS TO BE IN CCF? SCI-SA

5. Current Status of CCF files (contd) SCI-SA