140 likes | 266 Views
EUSO Calibration Databases. Getting Started. M.C. Espirito Santo, Munich, November 2003. Context. Archives and databases (DB) have been identified as one of the issues to be addressed in priority when planning the EUSO data handling system, in the context of the SODC.
E N D
EUSO Calibration Databases Getting Started... M.C. Espirito Santo, Munich, November 2003
Context • Archives and databases (DB) have been identified as one of the issues to be addressed in priority when planning the EUSO data handling system, in the context of the SODC • The reconstruction/analysis modules of ESAF are being build and the need to access different types of external information is one of the main issues (DB I/F expected to represent large fraction of code) ... the problem should probably be addressed as one • Gain experience and perform relevant tests rather early • Modularity and growing capability required
UIF User I/F HK archive Monitoring logs TM reception, processing and monitoring calib matrices archive E/pos calib files MADB manager science data archive TC generation, Planning and maintenance atm param archive Instr users manual EDBIF SW archive ... external databases SODC - Archives, databases and user interface UIF: User I/F MADB: Mission Archive and DB EDBIF: External DB I/F
RecoFramework Atm parameters Pattern recognition Track fitting GetDirection GetXmax GetHmax FindEnergy ParticleID ... ... ESAF reconstruction modules ESAF sim Root file Real data Config file InputModule RecoEvent Atmosphere DB Detector Calib DB ISS orbit/attitude DB
Getting started • Start discussion on DB contents • As agreed in the SIM/REC meeting at CERN, discuss detector calibration DB contents • Start planning a structure that: • Can be used within ESAF in the near future • Has enough potential to be a useful testbed for the future • Not for tomorrow, but could be addressed with the next 6 months • In this meeting: just some hints to start the discussion
EUSO DB: form & contents Only questions for the time being... • One or several DB ? • Which type of DB ? Which SW and access tools? • Organisation/inter-relations are crucial point! And highy dependent on • contents specification • Which information do we want to store? • Which parameters do we need to get for reconstruction? • I/F with end-to-end simulation and reconstruction • Accessing different types of info with single tool (external DB)
DB & ESAF – for discussion! • ESAF has an OO approach • Define DB info object (complex singleton object or hierarchy of objects) • Define method to fill it First implementation very simple (e.g. read ascii file), but defines the I/F ! • Modular: several inter-related DB: atmosphere, detector calib, ISS, ... • ESAF is Root based • Some popular query languages already supported within Root • MySQL could be a for-free, Root-compatible way of starting to explore relational databases and SQL-based approaches • Concurrent access problems: not for now. POOL ?
DB & ESAF – for discussion! • ESAF has an OO approach • Define DB info object (complex singleton object or hierarchy of objects) • Define method to fill it First implementation very simple (e.g. read ascii file), but defines the I/F ! • Modular: several inter-related DB: atmosphere, detector calib, ISS, ... • ESAF is Root based • MySQL could be a for-free, Root-compatible way of starting to explore relational databases and SQL-based approaches • Final choices and implementations details: not for now • POOL ?
Detector calibration DB Requires some basic assumptions... • How does the trigger and readout electronics work ? • Data contents • Trigger: basic scheme and tunable parameters • Which calibration information will we have? • Collected information • Information to be used on reconstruction • Information used to generate configuration parameter for uploading => Based on the RedBook preliminary issue
Trigger and readout Read-out data (for the hit macrocell and nearest neighbours): • ORed (X,Y) coordinates of hit pixels in each macrocell (ambiguous) • # photons per pixel (unambiguous coordinates – pixel ID) • (Analog) charge integration signal for each pixel (PMT?) • Trigger system: • Pixel signal compared to analog treshold (10 ns sampling) to recognise the arrival of a single p.e. event and count pulse • Counts per pixel in 1 GTU compared with pre-set value. If pixel-level trigger issued, (X,Y) lines marked into memory ad pulse counting enabled for the rest of the GTU • When counts from enabled pixels macrocell reach pre-set values, a macrocell level trigger is issued • SW-reconfigurable trigger looks for time-persistency patterns at Mcell trigger level. In case of alert it activates a Mcell level hard-wired (X,Y) proximity device.
Calibration • Lenses • Filters and optical adapters • FS photodetectors • FE and trigger electronics • Absolute calibration mostly done on ground Gains (G) and pedestals (p) Single p.e. peak • On-board: relative calibrations (stability) • Stable illumination of full FS (~1s, dayly basis ) • Threshold scan => p.e. signal discriminator level ~ 4 min, 54 Mbit /Mcell, one complete FS threshold scan every 2 months. Data to be analysed on ground, thresholds to be uplinked
Calibration DB – Info for reconstruction Digital: Npe = (signal – pedestal) x inneficiency correction • Pedestal map (analog and digital) • in similar background conditions! Check with different GTU of same event? • Dead/Noisy pixel map • Spatial proximity... • Inneficiency correction map (?) • If threshold high w.r.t. p.e. Peak • pileup • Analog: Q to Npe gain factor • Background level information • Moon phase and rise/set time • Human light world map (and ISS orbit coordinates!) Analog: Npe = (Q – pedestal) x Gain factor Ground calibration info stored on DB and updated with on-flight info
Calibration DB – Info for onboard config Information to be uplinked (on-board configuration files): • HV map • Gain map (?) • Analog Threshold map • 2 digital comparator levels per macrocell • Pixel mask map
DB contents - summary • Raw calibration data • Signal per pixel for full iluminated FS • Signal per pixel for “pedestal runs” • Threshold scan for each pixel (much less frequent) • Extracted calibration parameters - updated maps of: • HV • Pedestals • Gains • edet • Inneficiency corrections • Tresholds • Mask • Background conditions info • ... • Calibration SW and documentation: here or in doc and SW DB? • ...