1 / 10

JANA and Raw Data

JANA and Raw Data. David Lawrence, JLab Oct. 5, 2012. Simulated and real data chains. Simulated Data. Real Data. Simulated data starts at point where translation table and calibration constants have already been applied. Translation table converts from: (crate, slot, channel)

elana
Download Presentation

JANA and Raw Data

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JANA and Raw Data David Lawrence, JLab Oct. 5, 2012

  2. Simulated and real data chains Simulated Data Real Data Simulated data starts at point where translation table and calibration constants have already been applied Translation table converts from: (crate, slot, channel) to detector system and channel id: e.g.(BCAL, module, layer, sector,end) Green trapezoids represent objects obtained directly from file

  3. Digitization Module Data Objects Data objects created at lowest level in JANA reflect the information contained in the data types produced by the digitization modules Df250PulseIntegral Df250PulseTime fADC250 • rocid, slot, channel . • itrigger…………………. • pulse_number ……… • quality_factory …….. • integral ………………… • rocid, slot, channel . • itrigger…………………. • pulse_number ……… • quality_factory …….. • time ……………………… where in DAQ this came from which (local) trigger this came from which pulse (4 max) this came from quality of identified pulse integral of identified pulse where in DAQ this came from which (local) trigger this came from which pulse (4 max) this came from quality of identified pulse time of identified pulse Df250TriggerTime Df250PulseIntegral Df250PulseRawData Df250PulseTime Df250WindowSum Df250WindowRawData Df250SteamingRawData

  4. Digitization Module Data Objects List of module types and descriptions maintained in DModuleType.h. Written by human for now, but could be derived from JInventory in future. F1TDC fADC125 fADC250 JLab TS JLab TI DF1TDCHit Df250TriggerTime Df250PulseIntegral ? Df250PulseRawData Df250PulseTime Df250WindowSum Df250WindowRawData Df250SteamingRawData ? ?

  5. EB Disentangler ROCs Disentangling is required ONLY for high luminosity running due to L3 trigger A A A B B B 1Aa1Ba…1Dg A B 123 123 123 123 123 123 123 123 C C C D D D C D 123 123 123 123 123 123 a b g 123 123 a 2Aa2Ba…2Dg A B L3 ER 123 123 C D 123 123 b 3Aa3Ba…3Dg A B Use 4 bits of the 12 bit Detector ID to hold module type 123 123 C D 123 123 g abg= crate ABCD = module 123 = event size size status Detector ID Num. Events status Detector ID Num. Events Num. of first event in block Num. of first event in block Module 1, event 1 Nevents from Module 1 Module 2, event 1 Nevents from Module 2 … Module 1, event 2 … …

  6. Two phase data interpretation Interpretation of input data will be done in 2 phases: I.) Parsing of the data blocks based on module type to create low-level data objects (e.g. Df250PulseIntegral) II.) Application of translation table to convert from DAQ indexing (rocid, slot, channel) to detector indexing (CDC, ring, wire) • Only the module type is required for phase I and that will be available inside the file (see previous slide) • Lots of low-level diagnostics can be done using the low-level data objects without requiring the translation table

  7. The three* databases of GlueX • JInventory • Database of electronics modules, crates, etc. • Plan to use for translation table as well • Translation table will be copied (when changes detected) into conditions DB • Conditions DB • Translation table will be read from here by reconstruction programs • Contains values related to running conditions that change as run period progresses • Will contain a value (or multiple values) for every run. Overhead from calibration DB style index layer would be costly (e.g. CLAS experience) • Calibration DB • Contains calibration constants • Values may span multiple runs or be included in multiple sets motivating an indexing layer *This does not include the EPICS Archiver DB, DocDB, etc. …

  8. Responsibilities • Parties responsible for detector systems will also be responsible for maintenance of the relevant translation table in the JInventory database • Tools will be made available with documentation to make this easy for anyone (if you are interested in helping to write these, let me know!) • Module maps and any other configuration info critical to operation of the DAQ will be maintained by the DAQ experts (i.e. the DAQ system will not rely on the Translation Table)

  9. Summary • Work has begun on event source code to read raw DAQ events into DANA • Several low-level objects have already been defined • Prototype already working with 2012 beam test and bench test data • https://halldsvn.jlab.org/repos/trunk/sim-recon/src/programs/Utilities/plugins/DAQ • Data parsing will be done in 2 phases allowing for a level of online monitoring that does not require a translation table • Requires embedding module types in data file • Translation table will be maintained in JInventory DB, but copied into Conditions DB • Copied as needed to maintain record of evolution • Reconstruction will access Translation Table through Conditions DB • Subsystem experts will maintain Translation Table through a set of tools written specifically for this.

  10. Generic pedestals?

More Related