L 3 Jeff Landgraf In July Hank

“L 3” 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.

n Point #1 – TPC is not going to be a slow detector. – TPC as fast, if not faster than EMC’s The Old System: 700 hz L 0 500 hz FEE’s RDO’s 100 hz RB SB’s 500 hz 100 hz EVB L 0 DST L 2 The New System: 700 hz Linux Farm RCF ? ? ? FEE’s RDO’s 500 hz ? ? ? 1 -5 khz Linux Farm RB/SB/EVB/L 2 Linux Farm RCF DST

So what is the role of L 2 / L 3? n It won’t be to abort TPC. n Why not? – L 2 detectors would have to be faster than TPC (at least 10 x faster to be worthwhile) – Gated Grid would have to be faster than TPC readout (10 x for to be worthwhile)

Reduce Data Volume? n 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 L 3 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) n 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 has been one of the biggest bonuses from both L 2 and L 3 n 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. n

Analysis n Calibrations – It would be very nice to see more detector calibration procedures get automated and move into the counting house – ideally in an L 2/L 3 like entity, could save weeks commissioning each year. n L 4 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 L 2/L 3 triggers, but are not! It is the event builders that determine data files. n I would like to expand express streams dramatically. n – 2005 pp. Production: 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 n n I’m pessimistic about high level triggers used to abort the TPC in the daq 1000 era. We need to put real effort into maintaining and improving some analysis capability in the control room for monitoring & calibrations. The function of L 2/L 3 like entities in the new system will be to support efficient offline analysis, not to trigger. New L 0 trigger ideas, detectors are the path for improving STAR’s trigger.