Here are a few notes regarding the structure of the EPIO data for the HEC beam tests. M. Lefebvre 19/07/2001 EPIO RECORDS The EPIO data file for the HEC beam tests is composed of records, each of which is composed of block(s) (also called bank or sub-blocks). The type of record is obtained by looking at the id of its first block. Details of the record structure and of the blocks can be found at http://wwwvms.mppmu.mpg.de/~huber/hecdaq/doc/epio_record.html which can also be accessed through http://wwwhep.phys.uvic.ca/~uvatlas/ We have the following records: - run header record Sepp confirms that - this is always the first record - there are only one such record per run - it contains only the run header block (id = 9) - slow control record Each slow control record starts with a slow control header block (id = 70). At the moment, we have only two slow control records, and they immediately follow the run header record. At the moment, the first slow control record contains - a slow control header block (id = 70) - a sps standard data block (id = 73) - a H6 beam file block (id = 74) At the moment, the second slow control record contains - a slow control header block (id = 70) - a slow control PC block (id = 71) At the moment, each slow control block (apart from the slow control header block) are unique in a run, but Sepp warns that it may well happened that some slow control block appear more than once in a run. - event record Each event record starts with an event header block (id = 1) Each event record ends with an event summary block (id = 32) At the moment, a typical event record contains - an event header block (id = 1) - a tdc block (id = 39) - a hec fadc block (id = 36) - a mwpc block (id = 33) can be missing - an event summary block (id = 32) It may happens that the mwpc block is missing. Also, in the past, we had had - a trigger fadc block (id = 37) for ATLAS level 1 trigger studies. For the Aug01-Sep01 run period, there will also be - a scaler block (id = 38) for intensity studies (Leonid). I will incorporate this into hec_adc as soon as possible (easy). For next year, Sepp confirms that there will be another block for the em fadc data. - ae em fadc block (id = ??) Also, the way the HEC data is packed will change. Sepp points out that the burst number is currently available in the event header block. Indeed, I have modified hec_adc to make this information (along with a few more) available in hec_evth.inc (this will be in my development version on the web before 21/07/2001). Obviously, event records occur many times per run. - burst summary record The desicion now is NOT to have burst summary records - run summary record Sepp confirms that - this is always the last record - there are only one such record per run - it contains only the run summary block (id = 10) It can be said that hec_adc is a framework only as far as event records are concerned. Indeed, the user_* routines allow a user to access events. But hec_adc is not a framework as far as slow control (or burst summary) records are concerned. The user can only here access whatever has been recorded by one or many previous passes over the data (at initialization or in a package). The run header pass is trivial. The slow control pass, with unique (non-header) blocks per run, is also trivial. This is why both passes are currently made at initialization time, before the packages (see src/hec_offline.f and src/hec_offline_ini.f as well as online/hec_online.f). But if many different slow control blocks were considered per run, then the slow control block processing would require a proper package (like ped, his, ntuple, etc). The same is true for the summary burst records in principle. So at the moment, the EPIO file typically looks like - run header record - run header block (id = 9) - slow control record - slow control header block (id = 70) - sps standard data block (id = 73) - H6 beam file block (id = 74) - slow control record - slow control header block (id = 70) - slow control PC block (id = 71) - event record - event header block (id = 1) - tdc block (id = 39) - hec fadc block (id = 36) - mwpc block (id = 33) can be missing - event summary block (id = 32) hec_adc does not look at it - event record .... - event record - run summary record - run summary block (id = 10) hec_adc does not look at it READING EPIO in hec_adc EPIO is initialized in hec_io_ini.f We have hec_adc.f --> hec_ini.f --> hec_io_ini.f (epinit, epsetw, epdefu) Apart from the packages (ped, his, etc.), there are only 3 types of passes over the epio data: - run header pass hec_runh_pass.f - slow control pass hec_slow_pass.f - normal pass hec_pass1.f, hec_pass2.f, hec_pass3.f a) hec_runh_pass.f The run header pass only looks for the run header record. We have hec_adc.f --> hec_offline.f --> hec_offline_ini.f --> hec_runh_pass.f ! the complete pass --> hec_nextevt_epio_runh.f ! look for the run header record --> hec_runh_epio.f ! unpack run header in hec_runh.inc We assume that the run header block is in ONE of the first 10 records. The current logic is as follows: hec_runh_pass.f do once --> hec_nextevt_epio_runh.f do over up to 10 records look for run header block (epread, epfrd) if found read it --> rewind the file (eprwnd) Note that hec_runh_pass.f does an eprwnd. This was done when we were not sure if the run header block was always in the first record. b) hec_slow_pass.f The slow control pass only looks for slow control records. We have hec_adc.f --> hec_offline.f --> hec_offline_ini.f --> hec_slow_pass.f ! the complete pass --> hec_nextevt_epio_slow.f ! look for the next slow control record --> hec_slow_pc_epio.f ! unpack pc block --> hec_slow_sps_epio.f ! unpack sps block --> hec_slow_beam_epio.f ! unpack beam block We assume that slow control blocks (pc, sps, beam) can be in many records, but that these records are never more than 10 records apart. We keep trying until we have found all 3 blocks at least once, or until we have reached the end of the file. We only keep the info of the last of each block read (there are only one of each for now). The current logic is as follows: hec_slow_pass.f do as long as hec_next_epio_slow.f has found, at least once, each one of the 3 slow control blocks --> hec_nextevt_epio_slow.f do over up to maxrecords=10 records look for slow control header block (epread, epfrd) if found, look for and read pc, sps, and beam slow control block --> rewind the file (eprwnd) Note that hec_slow_pass.f does an eprwnd. c) hec_pass1.f, hec_pass2.f, hec_pass3.f (and other similar routines in package passes) The normal event pass only looks for event records. We have hec_adc.f --> hec_offline.f --> hec_pass1.f (or 2, 3) ! the complete pass --> hec_nextevt_epio.f ! looks for next event record --> hec_evth_epio.f ! unpack event header block --> hec_dwpc_epio.f ! unpack mwpc block --> hec_adc_epio.f ! unpack hec fadc block --> hec_scaler_epio.f ! unpack scaler block (only in Aug01) --> hec_tdc_epio.f ! unpack tdc block The current logic is as follows: hec_pass1.f do as long as hec_nextevt_epio.f finds the next event record, as long as the desired number of events is not reached --> hec_nextevt_epio.f do over up to maxrecords=10 records look for event header block (epread, epfrd) if found, look for and read other event record blocks --> rewind the file (eprwnd) Note that, clearly, hec_pass1.f does an eprwnd. COMMENTS FOR ATHENA DESIGN If we make the associaton events <-> records, then in general the beam test data contain different types of "events". I don't know how to deal with this. If the combined beam test data is as it is now, then only the first 3 records (and the last) are not of the traditional event type (adc's). Perhaps these first three records can be read at initializaion and stored somewhere so that other algorithms can get at them? In particular, for monitoring it would be useful to be able to fill some histos with slow control data. We need to think carefully about how to deal with special records.