1 / 24

Architecture validation and Physics performance

Architecture validation and Physics performance. Carlo Schiavi. Purpose of this study. The purpose of the analyses presented here is:

onaona
Download Presentation

Architecture validation and Physics performance

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. Architecture validation and Physics performance Carlo Schiavi

  2. Purpose of this study The purpose of the analyses presented here is: • to validate MCC-DSM architecture, studying its performance and robustness under nominal conditions, and comparing them with the ones obtainable from the MCC-D2 that was implemented using a less dense technology (DMILL); • to evaluate inefficiencies of the MCC in pessimistic working conditions but with a realistic physical content of data and to estimate their impact on the analysis and reconstruction of interesting physical channels.

  3. Architecture validation: layout Insertable layout: • Barrel: 3 layers with 5.05, 8.75 and 12.25 cm radius. • End-Caps: 3 disks placed at 49.5, 58.0 and 65.0 cm along Z axis. • Pixel size: 50x300µm2 for the b-layer and 50x400µm2 in the others modules.

  4. Architecture validation: event sample Physical conditions: • event sample: 1500 b-jets from Higgs decays (mH=100GeV/c2); • average pile-up events: 24; • LEV1 selection rate: 100 kHz; • electronic noise occupancy: 10-5Hit/Pixel/BCO. Front-End configuration: • ideal model, no inefficiencies. SimPix simulation scope: • single b-layer module at =0. Worst case conditions for the MCC at nominal occupancy

  5. Architecture validation: MCC set-up MCC parameter ranges: • Receiver FIFO depth: from 32 to 128 words. • Output serial line bandwidth: 40, 80 and 160 Mbit/s. MCC description: • reconstruction algorithm was not yet updated (MCC-D2)… • …but the output data format used was the MCC-DSM one, with the correct word sizes; • all hits contained ToTinformation.

  6. Architecture validation: performance 40 Mbit/s output rate • every configuration shows a1520% inefficiency; • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows; • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows; • both these inefficiencies are connected to output link saturation.

  7. Architecture validation: performance 40 Mbit/s output rate • every configuration shows a 1520% inefficiency; • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows; • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows; • both these inefficiencies are connected to output link saturation.

  8. Architecture validation: performance 40 Mbit/s output rate • every configuration shows a1520% inefficiency; • using small Receiver FIFOs, hits are lost due to Receiver FIFO overflows; • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows; • both these inefficiencies are connected to output link saturation.

  9. Architecture validation: performance 40 Mbit/s output rate • every configuration shows a1520% inefficiency; • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows; • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows; • both these inefficiencies are connected to output link saturation.

  10. Architecture validation: performance 40 Mbit/s output rate • every configuration shows a1520% inefficiency; • using small ReceiverFIFOs, hits are lost due to Receiver FIFO overflows; • with bigger Receiver FIFOs, LEVEL1 triggers (i.e. entire events) are lost due to PendingLev1FIFO overflows; • both these inefficiencies are connected to output link saturation.

  11. Architecture validation: performance 80/160 Mbit/s output rate • MCC-DSM (128 words) is perfectly efficientin nominal load conditions, as every set-up with more than 32 words; • MCC-D2 (32 words) is nearly critical: hits are lost both with 80 (0.3%) and 160 (0.015%) Mbit/s output rate; • Receiver FIFO occupancy is almost 5 times lower for the MCC-DSM (128 words) than than for the MCC-D2 (32 words).

  12. Architecture validation: performance 80/160 Mbit/s output rate • MCC-DSM (128 words) is perfectly efficient in nominal load conditions, as every set-up with more than 32 words; • MCC-D2 (32 words) is nearly critical: hits are lost both with 80 (0.3%) and 160 (0.015%) Mbit/s output rate; • Receiver FIFO occupancy is almost 5 times lower for the MCC-DSM (128 words) than than for the MCC-D2 (32 words).

  13. Architecture validation: performance 80/160 Mbit/s output rate • MCC-DSM (128 words) is perfectly efficientin nominal load conditions, as every set-up with more than 32 words; • MCC-D2 (32 words) is nearly critical: hits are lost both with 80 (0.3%) and 160 (0.015%) Mbit/s output rate; • Receiver FIFO occupancy is almost 5 times lower for the MCC-DSM (128 words) than than for the MCC-D2 (32 words).

  14. Architecture validation: robustness MCC-DSM b-layer set-up: • Receiver FIFO: 128 words; • output transfer rate: 160 Mbit/s. Robustness: • up to occupancies 4 times greater than the nominal one; • to possible problems on one output link; • up to trigger rates 2 times higher than the nominal maximum one; • to different detector geometries.

  15. Architecture validation: robustness MCC-DSM b-layer set-up: • Receiver FIFO: 128 words; • output transfer rate: 160 Mbit/s. Robustness: • up to occupancies 4 times greater than the nominal one; • to possible problems on one output link; • up to trigger rates 2 times higher than the nominal maximum one; • to different detector geometries.

  16. Architecture validation: robustness MCC-DSM b-layer set-up: • Receiver FIFO: 128 words; • output transfer rate: 160 Mbit/s. Robustness: • up to occupancies 4 times greater than the nominal one; • to possible problems on one output link; • up to trigger rates 2 times higher than the nominal maximum one; • to different detector geometries.

  17. Architecture validation: robustness MCC-DSM b-layer set-up: • Receiver FIFO: 128 words; • output transfer rate: 160 Mbit/s. Robustness: • up to occupancies 4 times greater than the nominal one; • to possible problems on one output link; • up to trigger rates 2 times higher than the nominal maximum one; • to different detector geometries. No hits nor triggers lost at nominal pile-up level, even working with a LEVEL1 selection rate of 200 kHz.

  18. Architecture validation: robustness MCC-DSM b-layer set-up: • Receiver FIFO: 128 words; • output transfer rate: 160 Mbit/s. Robustness: • up to occupancies 4 times greater than the nominal one; • to possible problems on one output link; • up to trigger rates 2 times higher than the nominal maximum one; • to different detector geometries. No hits nor triggers lost at nominal pile-up level, even simulating the TDRlayout, where the b-layer had a radius of ~4 cm.

  19. MCC configuration: similar to MCC-D2, not to MCC-DSM, which would have shown no inefficiencies; Receiver FIFO: 32 words; output transfer rate: 80 Mbit/s. Front-End configuration: ideal model, no inefficiencies. Simulation scope:entire detector. Physical conditions: event sample: 500 b-jet and 1000 u-jet events; three different pile-up conditions, giving detector occupancies equal to the nominal one, or 1.5 and 2 times higher; electronic noise occupancy: 10-5Hit/Pixel/BCO; LEV1 selection rate: 100 kHz. Physics performance: event sample

  20. Physics performance: inefficiencies Results: • lost hits percentage grows with average detector occupancy; • inefficiencies are peaked on the b-layer; loss of space-points which mainly contribute to give a better resolution on impact parameter: we can expect an efficiency loss for track reconstruction and b-tagging algorithms. Maximum inefficiency: 3% Occupancy: equal to nominal one

  21. Physics performance: inefficiencies Results: • lost hits percentage grows with average detector occupancy; • inefficiencies are peaked on the b-layer; loss of space-points which mainly contribute to give a better resolution on impact parameter: we can expect an efficiency loss for track reconstruction and b-tagging algorithms. Maximum inefficiency: 12% Occupancy: 1.5 times higher than nominal one

  22. Physics performance: inefficiencies Results: • lost hits percentage grows with average detector occupancy; • inefficiencies are peaked on the b-layer; loss of space-points which mainly contribute to give a better resolution on impact parameter: we can expect an efficiency loss for track reconstruction and b-tagging algorithms. Maximum inefficiency: 40% Occupancy: 2 times higher than nominal one

  23. After words MCC-DSM performance: • the solution developed by the Genoa team for the MCC-DSM implementation is fully efficient in nominal conditions and very robust to increases in detector load and to possible problems on one output link; • the previous DMILL implementation (MCC-D2) wouldn’t have been as robust, being in critical conditions even at its maximum output rate. Impact on interesting events reconstruction: • inefficiencies are peaked on the b-layer; • that means losing those space-points which mainly contribute to the impact parameter resolution, with consequent efficiency loss for track reconstruction and b-tagging algorithms based on pixel detector data.

  24. What’s next • Correctly evaluate Front-End inefficiencies and their impact: an up-to-date model of FE must be developed, to estimate the percentage of hit lost before they are transferred to the MCC; • repeat this kind of study using an updated model for MCC behaviour:new Receiver and EventBuilder algorithms must be correctly simulated… …anyway… the new features shouldn’t affect the results for MCC performance as: • FE inefficiencies can only reduce MCC load; • Receiver and EventBuilder new algorithms should prove more efficient than the old ones.

More Related