1 / 10

Optimizing TPC Detector Performance and Data Management in the New System

In response to inquiries about the upcoming meeting, this document explores key considerations for the TPC (Time Projection Chamber) within our new system architecture. It challenges assumptions about the speed of current detectors and emphasizes a need for improved data volume management techniques, including potential reductions in data size and enhancements in tracking algorithms. Moreover, it underscores the importance of calibrations, monitoring, and expanding express streams to improve data analysis efficiency. The overall goal is to optimize performance without compromising crucial functionalities.

hiram-case
Télécharger la présentation

Optimizing TPC Detector Performance and Data Management in the New System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. “L3” Jeff Landgraf

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

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

  4. 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)

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

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

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

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

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

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

More Related