Questions to be addressed for ATLAS Menu Coordination Group.
The Menu Coordination group is proposing six menus for early running.
See also the presentations on
April 15th, 2009 and
April 27th, 2009
- Cosmic v1:
- Thresholds: Muon thresholds in exclusive mode for cosmic running, most items are similar to what we ran with in October 2008
- Streaming: L1-based streaming including cosmic streams such as IDCosmic, DownwardMuons, etc
- Calibration triggers: Available (need to confirm)
- Active Date: Until June 2009
- Cosmic v2:
- Thresholds: Differs from Cosmic v2 in the muon thresholds, 4 set to inclusive mode (physics type thresholds) and only two (one for RPC and one for TGC) set to exclusive mode needed for commissioning the muon triggers
- Streaming: L1 based streams as in Cosmic_v1
- Calibration triggers: Available (need to confirm)
- Active Date: Until start of beam
- Initial Beam:
- Thresholds: L1 thresholds same as cosmic_v2 but with many items ANDed with BPTX where relevant. Several additional triggers for single beam and early collisions introduced including full scan reconstruction seeded off random/MBTS or even low physics thresholds to exercise HLT chains
- HLT: While all L1 and HLT chains will be in the menu, they will be enabled and activated gradually. In the beginning, we expect to enable only L1, then HLT in pass through, then actively enable HLT selection
- Calibration triggers: Not available
- Streaming: L1-based detector streams (same as Cosmics menu) but dedicated Cosmic streams during standalone mode dropped
- Active Date:
- Initial Beam with Bunch groups (BGRP):
- Thresholds: BGRP become available, L1 items Anded with BGRP where relevant instead of BPTX. Some L1 items can be duplicated (one using BGRP and one using BPTX).
- Calibration triggers: Calibration triggers that need to be configured with one of the 7 BGRP settings can go in now
- Streaming:
- Active Date:
- Initial Beam with BGRP and Physics:
- Thresholds: Can recover lost physics thresholds, some spare inputs (used for calibration triggers) and triggers for LUCID, ZDC, BCM, TRT recovered.
- HLT: Will be able to enable HLT chains with recovered L1 items
- Calibration triggers: Available
- Streaming:
- Active Date: To be deployed when MBTS will release its L1 bits
- 10^31 menu
- Thresholds: Same as 'Initial Beam with BGRP and Physics' menu, except optimized thresholds in light of our experience with the early running.
- Calibration triggers: Available
- Streaming:
- Active Date:
Cosmics v1 and v2 menus
- Cosmic triggers:
- Purpose: Verification of EM scale and timing calibrations
- Triggers:
- All cosmic triggers are interesting
- IDCosmics the most interesting
- Calibration triggers:
- Purpose: Measurement of PMT response and noise stability
- Triggers:
- Laser at 0.5Hz (request to move this to 1Hz): Partial event building, Tile+L1Calo only
- Tile Noise at 1Hz (0.5 is a minimal): Partial event building, Tile+L1Calo only
- MinBias trigger and application
- Special Runs:
- None
- Outstanding issues:
- Need to optimize selection for a good Tile DPD (Irene working on this)
Initial Beam and 10^31 Menus
- Projective muons:
- Purpose: Validation of EM scale
- Triggers:
- Any of the isolated muon chains
- Horizontal muons:
- Purpose: Validation of the EM scale, calibration of the ITC scintillators, in-situ calibration of energy scale in hadronic end-caps
- Triggers:
- Scraping muons: Events with the RF off
- Halo muons: Need some trigger for the beam backgrounds. Maybe a MBTS or TGC trigger only on one side (probably with coincidence triggers is the 4BC time difference between the TGC sides). Then use HLT to look for clusters of energy in Tile.
- trk9i_loose triggers:
- Purpose: Validation of the hadronic response
- Triggers:
- trk9i_loose which provides isolated-at-the-ID tracks with no isolation at the calorimeters (no bias), only minimal energy deposition in EM+HAD. Some events will have mips in EM and have a hadronic shower only in Tile.
- MBTS Triggers:
- Purpose: Check of calorimeter uniformity and cell inter-calibration
- Triggers:
- Any MBTS trigger
- Splash Events:
- Purpose: Checks of the fine timing settings
- Triggers:
- Need 20 events to achieve 0.1ns precision, 50 events to achieve <0.1ns precision
- Cosmic triggers:
- cosmic menus do not seem well defined yet in the empty bunches
- Calibration triggers:
- Purpose:
- Triggers: Measurement of PMT response and noise stability
- Laser at 0.5Hz (request to move this to 1Hz): Partial event building, Tile+L1Calo only
- Tile Noise at 1Hz (0.5 is a minimal): Partial event building, Tile+L1Calo only
- MinBias trigger and application
- Special Runs:
- Splash Events: 50 events would be perfect, 20 events at the lower level. Needed for timing verification.
- Scrapping muons: A day or two run with scraping events (with muon chambers on). This would be used to get better cross-checks on the calibration. If we get this, we would not need any horizontal trigger as scraping events are better collimated.
- Inner detector tracks: trk9i_id trigger with no isolation in calorimeter. This is 45Hz at EF without prescale. Would like a day or two with this trigger unprescaled. Needed for verification of the hadronic scale in Tile
- D-cell run: One dedicated run we need is a physics run where the D-cell calibrations are set to 1.0 (compared to 1.20). This is to test that there are no biases in the L1Calo calibration due to the gain differences in the D-cells. This run can not be taken until we are using the 'Initial beam with BGRP and Physics' or '10^31' menus. Need to get from L1Calo the estimated number of events needed.
- Outstanding issues:
Open Questions to be discussed by Tile
See the list of
detector related issues and the
list of general issues from Beatenberg.
The morning meeting? Or a dedicated meeting?
When can we move from the L1 bit streaming to physics streaming
An important question, we relied heavily on the L1 bit streaming last year. The physics groups will want to move to the physics streams as soon as possible. We need to define when this is acceptable to us.
How will the dynamic masking be handled
Dynamic masking is referring to for example a ROD going BUSY and it is dropped from the readout without the run stopping. We need to give requirements to whether or not this scenario merits us to stop the run or just continue on.
--
MonicaDunford - 17 Apr 2009