Observations

- By zooming into the Z distribution, one can observe that the events with eta in the CSC region are not peaking at zero, but are a bit displaced
- I need to understand how the Eta and Phi are defined for the reconstructed tracks. Where are these values extracted?

• Inner X vs Y:

• outer X vs Y:

• Inner R vs Z:

• outer R vs Z:

Remarks

- The plot labeled as 0.9 < |eta| < 0.2.4 are obtained by selecting events which have rechits in CSC, not by looking at the reconstructed eta.

Raw events

• From the associated Raw Digi in the reco'd sample

• Eta and Phi distributions for all raw tracks:

• The phi values from the CSCTF (in bits) is transformed using the class L1MuTriggerScales. The value is returned for each sector, so it is supposed to cover a range of 60 degrees (~ 1.0472 rad). We observe phi exceeds the range of the foreseen 60 degrees. On the other hand in all the events there are several candidates (more than half) coming from single (mode 11) and halo triggers (mode 15). Therefore for the final study we exclude these trigger and get the following Basic distribution on raw tracks:

Observations

- By removing the tracks with mode 11 and 15, the Phi distribution falls in the correct range
- The periodicity in sector distribution is understood: sectors 3,6,9 and 12 are horizontal, thus it is less probable for a cosmic track to be reconstructed in the detector.

Pt Raw CSCTF vs Pt Reco'd muons

In order to match the information coming from the CSCTF to the correspondent reconstructed track, I have been using the phi and eta coming from the rechits. Given a reco'd track, the information of the rechit closest to the key station and key layer is accessed and used as phi and eta for the muon. For the CSCTF track the phi and eta coming out from the LUT are used. As observed in plot phiRaw-chain.png the phi variable ranges from 0->60 degrees and it is defined inside a sector. To convert the CSCTF phi, PhiTF, in a range from [0,2Pi], I used the following formula:

fmod( PhiTF + ((sector-1)*PI/3) + (PI/12), 2*PI)

• Delta Eta:

• Delta Phi:

Observations:

1. The peak centered at 0 come from the matching between the reco'd track and correct CSCTF track ("signal").
2. The spread bumps on the sides comes from the matching between the reco'd track and the wrong CSCTF tracks ("background")

Selection of events

- Have RecHits in CSC
- |EtaRechit-EtaTF| < 0.5
- |PhiRechit-PhiTF| < 0.5
- mode 11 and 15 excluded

With this selection applied, the following plots are produced:

• Mode distribution:

• Pt comparison:

Observation

- While the definition of Pt LUT validation has not been established yet, one can observe, in particular from the profile plot, that the CSCTF seems to pick the "correct" transverse momentum range, i.e. for small value of reco'd muon Pt, the CSCTF assigns small value of Pt in the correct range for the correspondent raw track. Remember that the output of the CSCTF for Pt (as well as for Eta and Phi) is binned and not a continuous distribution.

Remark

- No additional cuts on the quality of the raw track or on direction of the track have been applied.

• q/Pt comparison:

Remark

- Since the charge from the CSCTF and the from the reconstructed muons does not always agree, as charge value I have been using the one returned from the reconstructed muons (e.g. plots below)

• q comparison:

PtReco dependencies

In order to parametrize the Pt coming out from the LUT, we plan to use the data from the CRAFT run and we need to look at the PtReco dependence of all possible variables we measure from the SP.

• PtReco as a function of DeltaPhi12:

• PtReco as a function of DeltaPhi23:

Remark

- DeltaPhi12 and DeltaPhi23 are reported in bit values (respectively 8 bits and 4 bits)

One would expect the Pt to decrease as DPhi12 (or DPhi23) increases. Instead, after bit ~100 we observe an increase of the Pt as DPhi12 increases. To better understand if this effect comes from a bug or is realthe sample is split according to the mode:

• MODE 2:

• MODE 6:

• MODE 8:

• MODE 11 (just for "fun"):

Observations

- Mode 2 shows the expected behaviour
- Not considering Mode 11, Mode 6 and 8 shows the not expected behaviour. Need further investigation. Most likely for these Modes I am not accessing the information in the right way...

-- GianPieroDiGiovanni - 28 Nov 2008