Home E-mail Notes Meetings Search

[ Home | Contents | Search | Start a new article | Reply | Next | Previous | Up ]


Referees' questions (2)

From:
Date: 4/21/98
Time: 3:03:48 PM
Remote Name: 137.138.115.189

Comments

Dear LHCb collaborators,

Here are the second list of questions from referees on Tigger/DAQ/Computing and Physics related questions yours Tatsuya

============================================================ Trigger/DAQ/Computing ------------------- >From Brian Foster

[1] General points 1) More information on Timing and Fast Control requirements

2) Luminosity measurement, how it is done, whether this requires any particular special DAQ capabilities, such as rate? Or time-stamping? If there will be some sort of forward-backward Roman pots for elastic scattering, what are the rates? What is the accuracy that can be obtained? How does it compare with whatever the machine will be using for lumi optimisation?

3) Related to the above, how to estimate dead-times as a function of particular triggers? Or will there simply be one overall dead-time number? Will it be averaged, or related to actual currents in particular bunches? Will latencies/rates for each trigger be a) available b) stored? What is the strategy envisage for changing trigger conditions during a fill, or over longer periods? What is the strategy for ensuring that all triggers have enough redundancy that other independent triggers are available to measure their efficiency?

4) Related to the above, how to deal with "satellite" bunches in the machine if they exist? This is a significant problem at HERA, where the proton beam can have as much as 10% of its intensity in the next rf bucket. In principle, the luminosity measurement/experimental trigger will react very differently to events from these satellites.

5) How sensitive are the various parts of the trigger to movements of the beam? There is a discussion for the vertex trigger, but how about the tracking trigger? For the vertex trigger, there statement is that the beam needs to be stable to 200 microns ... although this will be true in the short term, over periods of weeks or months experience at HERA eq shows that the beam can drift by significantly more than this? What is your strategy to cope with this?

6) Clearly small changes in the characteristics of the non-b signal can have major effects on trigger rates and efficiencies. What variations are caused by using the extremely limits of the currently determined proton structure functions? In particular, how do such extremes effect the E_t and p_t distributions? Will the relevant x regions for LHC have been measured by HERA, and with what precision?

7) How to cope with variations in the machine backgrounds by factors or 2 - 4? For ATLAS/CMS, it is always said that the real interaction rate far exceeds any machine backgrounds..is this also true for LHCb?

8) Figure 6.3 on page 34 of the TP worries me. If the L0 trigger rate increases by 25% from the design (is 1 MHz design, or maximum?) then you start to run into trouble very quickly.....shouldn't you to be safe really reduce the readout time to options A or B, i.e. 500 nsecs?

[B] More specific points 1) 3D flow in general -What is the status of the 3D flow chip? -Have prototypes been made? -If so, what was the performance? -In the 3D flow implementations, what happens when individual processors malfunction?

2) Muon trigger: -What efficiencies are assumed per chamber and station? -What happens if sectors malfunction/need to be switched off? -For the 3D flow implementation - 45K separate adjustable delays seems very undesirable? Even if this is possible, are the delays stable at the 3 - 5 nsec level presumably required to remain in synch at the 3D flow chip? -Note 97-024 implies a solution with the processors in front of the shielding wall. Surely the radiation levels here will be too high?? -Why are the results for the muon trigger shown in 12.23 of the Tp so different from those in note 98-021? Given that the improvement is shallow as a function of cut-off, particularly for the pi and mu cases, is this a useful trigger, particularly since in principle one ought to compare with making the same harder pt cut-off at L0?

3) Pile-up veto. -How long does it take to get all the data in for an average event? -What is the estimated latency? -What happens if coherent noise causes all strips to fire? -Where is this processor physically?

4) L0 decision unit -Why does it use the gamma coordinates at the preshower? -Does the L1 trigger have access to any tracking detector info. for gamma triggers? The TP implies not - but then can L1 improve on the gamma trigger?

5) L1 vertex trigger -What happens if some sections of first 3 stations are dead? -Doesn't the multiplication of probabilities to give a total event probability produce a multiplicity dependent bias? -How does the tail of the latency vary with increasing noise in the detectors? -With increasing beam background? -What is the L1 VTX rejection for events already passing L0? Note 98-006 implies the numbers are for all events, not L0 passthroughs. -What are the arrangements for monitoring and checking performance - deciding on requirement for new alignment constants? This is a complex and high performance system - monitoring will be vital.

6) Tracking trigger -I am not clear of how much is gained by the level 1 trigger if the vertex trigger is already applied - does it select different events? -In general, more detail on the overall efficiency, latency, performance of the L1 would be helpful.

7) Level 2 -It would be nice to see figures for c separate from uds. What suppresses c particularly in L0 and 1? Simply the pt cuts?

8) DAQ -What happens to the readout network if the event size/throughput increases by 25%? 50%?

9) Computing -The requirements on the ODBMS are truly frightening. BaBar is finding problems with ODBMS/Operating system compatibility. What steps will you take/how confident are you that you will have a product which will cope with your requirements?

----------------------- >From Andrey Rostovtsev 1) Have you considered a possibility to build a high-pt low-level track trigger (similar to HERA-b)? This option seems to have more flexibility than the calorimetric hadron trigger. Example of tests of gas pixel chambers for HERA-b is encouraging: high efficiency, low material thickness, possibility of fast signal within 25ns for cells of 4*4mm, low occupancy allowing to combine few small cells into one channel, presumably better transverse momentum resolution than calorimetric trigger, compactness in space giving more freedom to use longitudinal space budget for the whole experiment, etc.

==================================================================== Physics related questions

>From Andrey Rostovtsev 1) Would it be possible to utilize slow charged hadrons for tagging in the present tracker configuration?

2) Kaon tagging. Could you please give the numbers for expected dilution for electrons, muons and kaons separately to see the weight of the Kaons

3) K+pi channel. It doesn't seem to be statistically limited if you even require only lepton tagged events. Isn't?

4) D+K* channel. Is it possible here to use the gamma-trigger to exploit D0-kpipi0 channel or pi0 from K*?

5) Have I forgotten something else, where the hadronic trigger gives a unique opportunity for physics reaches of the experiment?