Difference between revisions of "Event size"
From GlueXWiki
m |
m |
||
| Line 9: | Line 9: | ||
One of the results of the meeting was the formation of a steering committee to oversee the effort to understand the event size. Members are Elliott W, David L, and Fernando B, representing the online, offline, and electronics efforts. | One of the results of the meeting was the formation of a steering committee to oversee the effort to understand the event size. Members are Elliott W, David L, and Fernando B, representing the online, offline, and electronics efforts. | ||
| − | + | Notes from first meeting 25-Sep-2007: | |
| − | * need to undersand board occupancies, average event size/rate, and burst size/rate | + | * need to undersand board occupancies, average event size/rate, and burst (worst case) size/rate |
| − | * need to understand header sizes and what data boards generate if there are no hits | + | * need to understand header sizes and what data the boards generate if there are no hits |
** minimize in production boards and for production running (vs debug modes) | ** minimize in production boards and for production running (vs debug modes) | ||
** header words can be removed at many stages: on board, by ROC, by EB, in farm, and by ER | ** header words can be removed at many stages: on board, by ROC, by EB, in farm, and by ER | ||
| Line 23: | Line 23: | ||
*** check periodically (not each event) | *** check periodically (not each event) | ||
*** others? | *** others? | ||
| − | * renormalized (scaled) Pythia | + | * event sources |
| − | + | ** will use renormalized (scaled) Pythia to generate hadronic events | |
| − | ** | + | *** See Alex's report on comparision betweeed renormalized Pythia and published data |
| − | ** | + | ** will use Geant to generate EM backgrounds (mostly pair production) from the coherent brem beam |
| − | ** | + | ** hadronic events can pass the trigger, or be accidental background for another trigger, |
| − | + | ** multiple events may pass trigger even though individually they wouldn't | |
| − | ** | + | ** need to be careful about time cuts, out of time tracks, tracks from previous event, etc. |
* need backgrounds from full energy range of incident photons, including low energy photons | * need backgrounds from full energy range of incident photons, including low energy photons | ||
* need to run MC with latest geometry, or at least one with a reasonable upper limit on material | * need to run MC with latest geometry, or at least one with a reasonable upper limit on material | ||
| − | * need to better simulation Level 1 trigger algorithm | + | * need to better simulation Level 1 trigger algorithm |
| + | ** can be applied to generated events or after simulation | ||
* Dave estimates we need the following computing/simulation time | * Dave estimates we need the following computing/simulation time | ||
** event generation goes quickly, perhaps only a few hours | ** event generation goes quickly, perhaps only a few hours | ||
| − | ** 1 week simulation Pythia events | + | ** 1 week simulation hadronic Pythia events, both triggers and accidental |
| − | ** 1 week simulation EM | + | ** 1 week simulation Geant EM background events |
| − | + | ||
* need to understand bytes per hit for all detector/electronics combinations | * need to understand bytes per hit for all detector/electronics combinations | ||
** is timing needed | ** is timing needed | ||
Revision as of 11:51, 27 September 2007
Introduction
The average event size determines backplane bandwidth requirements, network bandwidth requiremens, number of modules per crate, and many other things. Fortunatly the DAQ system is highly modular and scalable, so accomodating even a doubling of the event size should be no problem. I.e. more crates may be needed, and perhaps a faster RAID system, but no change in architechture would be needed. See the discussion in the minutes from the 29-Aug-2007 Online Working Group meeting dedicated to this topic.
Steering Committee
One of the results of the meeting was the formation of a steering committee to oversee the effort to understand the event size. Members are Elliott W, David L, and Fernando B, representing the online, offline, and electronics efforts.
Notes from first meeting 25-Sep-2007:
- need to undersand board occupancies, average event size/rate, and burst (worst case) size/rate
- need to understand header sizes and what data the boards generate if there are no hits
- minimize in production boards and for production running (vs debug modes)
- header words can be removed at many stages: on board, by ROC, by EB, in farm, and by ER
- need to understand data rates at each stage
- board should not put out chip-specific information, only board-level information (in production mode)
- possible ways to recognize that all boards are reporting
- header/trailer words for each event
- ROC-generated bit mask for each event
- error flags if a board did not report, no data generated
- check periodically (not each event)
- others?
- event sources
- will use renormalized (scaled) Pythia to generate hadronic events
- See Alex's report on comparision betweeed renormalized Pythia and published data
- will use Geant to generate EM backgrounds (mostly pair production) from the coherent brem beam
- hadronic events can pass the trigger, or be accidental background for another trigger,
- multiple events may pass trigger even though individually they wouldn't
- need to be careful about time cuts, out of time tracks, tracks from previous event, etc.
- will use renormalized (scaled) Pythia to generate hadronic events
- need backgrounds from full energy range of incident photons, including low energy photons
- need to run MC with latest geometry, or at least one with a reasonable upper limit on material
- need to better simulation Level 1 trigger algorithm
- can be applied to generated events or after simulation
- Dave estimates we need the following computing/simulation time
- event generation goes quickly, perhaps only a few hours
- 1 week simulation hadronic Pythia events, both triggers and accidental
- 1 week simulation Geant EM background events
- need to understand bytes per hit for all detector/electronics combinations
- is timing needed
- adc + tdc vs adc only
