# Presentation: 245481

## “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.

- “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

- TPC as fast, if not faster than EMC’s

- L0

- FEE’s
- RDO’s

- RB
- SB’s

- EVB

- Linux Farm
- RCF

- DST

- L2

- L0

- FEE’s
- RDO’s

- Linux Farm
- RCF

- DST

- Linux Farm
- RB/SB/EVB/L2

- 700hz

- 100hz

- 100hz

- 500hz

- ???

- 500hz

- The Old System:

- The New System:

- 700hz

- 1-5khz

- 500hz

- ???

## 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.