100 likes | 206 Views
“L3”. Jeff Landgraf. In July, Hank sent me a message asking if I had any talks for this meeting. “No, but I have some issues that could be discussed.” and followed up with a few paragraphs of rather obvious, unconsidered, unprioritized, inconclusive, rambling opinions. Here they are.
E N D
“L3” Jeff Landgraf
In July, Hank sent me a message asking if I had any talks for this meeting. “No, but I have some issues that could be discussed.” and followed up with a few paragraphs of rather obvious, unconsidered, unprioritized, inconclusive, rambling opinions. Here they are.
Point #1 – TPC is not going to be a slow detector. • TPC as fast, if not faster than EMC’s The Old System: 700hz 500hz ??? 100hz 100hz L0 FEE’s RDO’s RB SB’s EVB Linux Farm RCF DST 500hz L2 The New System: 500hz ??? 1-5khz 700hz Linux Farm RB/SB/EVB/L2 Linux Farm RCF FEE’s RDO’s L0 DST
So what is the role of L2 / L3? • It won’t be to abort TPC. • Why not? • L2 detectors would have to be faster than TPC (at least 10x faster to be worthwhile) • Gated Grid would have to be faster than TPC readout (10x for to be worthwhile)
Reduce Data Volume? • Write out tracks? • 8 helix parameters (including dedx & track length), all floats. Need ~8 words per track not including niceties like chisquare, number of hits. Current L3 structure has 13 words. • Need multiple origins for each track to extrapolate to origin and to outer detectors? • Between 16-26 words needed to define track. • Clusters only are 2 words / hit, so a 20 hit track needs only ~40 words. • Perhaps there is a 50% data volume savings… but • Calibrations need to be final before run starts. • Tracking algorithm would need to be trusted.
Reduce Data Volume? (continued) • Pileup rejection… • Do tracking • Tag hits from tracks • Remove hits from datafile if they come from pileup events • Idea suffers from same calibration / verification issues as writing out tracks.
Monitoring • Monitoring has been one of the biggest bonuses from both L2 and L3 • Its important to keep this functionality up (and to keep expanding it), even if in the end there is no room for higher level triggers.
Analysis • Calibrations • It would be very nice to see more detector calibration procedures get automated and move into the counting house – ideally in an L2/L3 like entity, could save weeks commissioning each year. • L4 trigger, used only to reject events from going to RCF is a very possible idea… But the purpose would be to lighten the load on the reconstruction rather than increase bandwith.
Express Streams • Express streams are always associated with L2/L3 triggers, but are not! It is the event builders that determine data files. • I would like to expand express streams dramatically. • 2005 ppProduction: if we separate EVERY trigger into separate stream, then only suffer ~9% data overhead. • Analysis chains could be specifically tailored to each trigger – in many cases (I believe) this would lead to much more efficient analysis. • Reconstruction could be better prioritized.
Summary • I’m pessimistic about high level triggers used to abort the TPC in the daq1000 era. • We need to put real effort into maintaining and improving some analysis capability in the control room for monitoring & calibrations. • The function of L2/L3 like entities in the new system will be to support efficient offline analysis, not to trigger. • New L0 trigger ideas, detectors are the path for improving STAR’s trigger.