This links to WebSearch.

The CMS Endcap RPC Analysis

the goal of CMS endcap RPC analysis is to confrim the peformance of RPC detector after assambling them to the york, especially RE1 which is assamble and tested by Peking University. One most important parameter is the efficiency, while other paramters such as spatial resolution is also survied, and they are based on the efficiency analysis. The Analysis is validated by MC simulation and then applied to commission data from 2010 collision runs.

Algorithm of Effciency for endcap RPC

the basic principle to estimate the RPC efficiency is to find the fired strip around expected impact position and compare the residual distance with certern acceptance window. Impact position is evaluated by the segment extraploation from CSC chamber which cover the same $\phi$ segment in the same ring and station. The one which impact onto the RPC surface is taken as a trigger, the residual to nearest fired strip(if found) is caculated then and used to estimate the efficiency. in MC validation the simHit on RPC detector itself is also involved by another algorithm to replace the impact position from segment extrapolation, this is to get a "true" RPC performance of the acknowledge to energy deposite in the same MC setting, and cross check with the segement extrapolation algorithm.

Extrapolation.png simHit2RPC.png

The algorithm also introduce in two improvement besides the extrapolation.

First a segment filter is applied to filter out possible noise from CSC segments, the assumption is one segment from a particle could probably leave other measurements on previous/next station along the trajectory path, so these two segments keep a similar direction. A threshold consist of both $\eta\ and $\phi$ is applied to handle the descrimination, segments do not have a matched partener is considered as a possible noise and will not be taken as the trigger event. The parameter is defined as deltaR=sqrt(deltaEta^2+deltaPhi^2)

CSCSegmentMatch.png

Second a r\pyramid/come projection is applied to cover the inaccuracy of CSC measurement and segment extrapolation, which is expressed by corresponding torelance range in $\theta$ and $\phi$. The cone with part of its projection outside the RPC surface is considered in each direction and lead to different handling. Corss edge along the RPC strip is considered a fake trigger, since the true trjectory might have chance to pass by the chamber, and the impact event will be dropped from the efficiency statistics. While corss along the $\phi$ direction will cause the algorithm trying to find fired strip from adjacent roll, except for RE1/R2 and RE1/R3 where the RPC chambers are not closely overlap.

RPCCone.png

MC Analysis

All MC analysis is running under CMSSW_4_1_5 with ideal globaltag.

The efficiency caculation for singal roll:

The MC analysis result with segment match filter are shown as following;

MatchV1Eff1D_RE13B.png MatchV1Eff2D_RE13B.png

Efficiency w.r.t incident angle:

Eta1DEffV3.png

Parameters for RPC cone projection:

The MC analysis result with RPC cone are shown as following;

RPCCone1D_RE13B.png RPCCone2D_RE13B.png

Data Analysis

In data analysis the software invironment is also CMSSW_4_1_5, with global tags individual to different runs. Serveral runs with large statistics during the 2010 collision is analyzed, with black list for RPCs which is masked or had HV/LV off. Also the RPCs worked unfer sigle gap mod is provide by another list. The algorithm parameters are just the same as in the MC analysis.

the 2010 data information:

name: RPCMonitorStream dataset: /RPCMonitor/Run2010B-v1/RAW

In data analysis we calculate the efficiency for a whole disk or endcap system with formular:

The analysis result for run147755 are shown as following;

run147755Eff1D_RE13B.png run147755Eff2D_RE13B.png

Total efficiency and average cluster size distribution for endcap:

2010Eff.png 2010ClusterSize.png

Efficiency and average cluster size distribution for run scanning:

2010RunScanEff.png 2010RunScanCS.png

Efficiency w.r.t Incident angle survey:

2010Theta2CS.png

Q&A

  • Q: Is the simHit method in the MC analysis also using CSC segments?
  • A: The simHit method actually did not use CSC segment. SimHit method is aim to provide a "MCTruth" reference for validating the segment extrapolation method. Since the particle deposite energy in the RPC sensitive region, there is a fixed efficiecny parameter for MC process to determine if the final signal could get the strips on fire. This is the "true" efficiency during the MC process, so a nice working segment extrapolation method should represent a same performance, if not, then we know the extrapolation algorithm have some defects and a further checking is needed.

  • Q: Why the upper half of the chamber (Local y > 0) is not illuminated on the first result of segment extrapolation(approval slide3)
  • A: The upper half of the chamber (Local y > 0) is not illuminated because the segment extrapolation try to match current segment with another segment come from previous/next station, which is called segment match filter. This filter based on the assumption that segments from a true particle usually leave parteners with similar direction along its trajectory, and single segment without parterners on other station could probably be condiered as noise. But for RE1/R3 case half roll B and total roll c could not have another segment for match, since the trajectory leave station1 disk and pass by station2. RE1/R3/C lost all the impact event. while roll B lost upper half of the occupency. The simHit method does not use CSC segment and the segment match filter, so the occupancy/efficiency distribute on full surface.

SegmentLostMatch.png

  • Q: And now on Slide7 you got the (0 cm < local y < 40 cm) part back. What happened before?
  • A: Because in final algorithm the segment match filter is disabled on RE1/R3/RollB_RollC, we prefer to survey as much RPC surface as possiable, actually the decresed of efficiency is trival.

  • Q: Where does this oscillation between odd and even chambers comes from?
  • A: The ocillation appears both in occupancy and efficiency. For Occupancy, oscillation is caused by the difference of CSC-CSC distance among odd and even chambers. Since there is bending between the stations for a muon trajectory, and bending is more heavy on high eta region. The segment match filter requires the trigger segment and its partener keep similar direction, and a threshold is set to estimate their consistency. For CSCs the chamber of even number, the distance to another chamber with same numbering on next station is more close, so they could pass the segment match filter in higer $\eta$ region and get more occupancy on the upper part of the RPC surface. While comes to efficiency the situaion is more complex, the CSC-RPC distance in current station take influence on the low efficiency distribution on RPC surface(why there is low efficiency region will be explain in next question), with the ocsillation both on occupancy and low efficiecny event rato, the total efficiency take an oscillation either. The following plots show the difference on occupancy and efficiency distribution on odd and even RPC rolls:

CompareMatchLocalOdd.png CompareMatchLocalEve.png

  • Q: Why there is low efficiency belt on the muon graphy?
  • A: In the CSC chamber, segment is made from six layer of Cathode/Anode measurement. On cathode the measurement uses centre of gravity and provides an accurate position. While in anode the measurement is from digital channel of ~10-14 grouped wires. So a single CSC chamber might provide the eta measurement with relatively large error. When a muon trajectory passes by the RPC top/bottom edge without impact point, the CSC segment could happen to deviate from the trajectory in eta direction. In such case the extrapolation falls onto the RPC sensitive area, which causes a fake event count by the efficiency analysis code, and could not get RPC response from the recHit record. That is what we investigate and confirm in the efficiency w.r.t incident angle plots, most low efficiency events concentrate on top/bottom, and those fake events are brought by large/small incident angle.

SegmentError.png

  • Q: On the efficiency w.r.t incident angle plots, could you explain the shape?
  • A: In general, the shape is a symmetrical high-peak-low-valley style. The low valley on both sides is due to the CSC measurement on theta which is less precise. trajectory passing by top/bottom edge will give a fake impact event, while the RPC does not get fired and so could not provide an efficient count. when coming to the peak, the explaination is those passing trajectories could not spread into such far away theta region(note the spread width is ~0.16-0.20, so low incident events from true trajectory plot will have a limit on spreading into high segment theta region. the same situation happen on the other side), then the remaining events are all from the center impact region, where the RPC could get fired. The following plot helps to explain how the high-peak-low-valley shape is made. Theta direction from the true trajectory is indenticated with symbol "T" plus a position fix "t", "c" and "b", which means top, center and bottom. while true trajectories pass by the RPC chamber is indenticated with fix "at" and "bb" which means "above top" and "bellow bottom". Further more these trajectories are measured by CSC and involve in bias, .i.e the "+", "0" and "-" with their mean on modification of theta measurement. For large theta part, on the high peak region, trajectories from center part impact on the top and bring high efficiency events. While on the low valley region, trajectories pass by RPC chamber bring fake impact event on less large theta range.

peak_valley_shape.png

  • Q: On data analysis, the efficiency w.r.t incident theta for RE+1/R3/B, the last two bin do not have error bar
  • A: Error bars correspond to the RMS of the cluster size. Here we use: double Mean = hist1->GetMean(); double MeanError = hist1->GetMeanError(); The last two bins have unique distribution on one bin, and no error bar value.

Time Schedule

2009.01

analyze the RPC endcap efficiecny, preliminary result was surveyed using cosmic data during the CRAFT09 committion

2010.01

analyze the RPC endcap efficiecny using 2010 collision data

2011.01

MC analysis, validated the algorithm again and found out fake trigger reason, re-analyze the runs with large statistics in 2010 data.

2013.08

Internal note draft is submit to the iCMS. CMSNoteID is CMS DN-2013/013.

2013.10

Make presentation for approval plots, answer questions about the approval plots, modify some expression

2013.12

Add a full set of plots for approval check, which cover all rolls region in RE1 endcap station. Internal note is updated and plots modified to cmsStyle.

-- HaiyunTENG - 21 Feb 2014

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng 2010ClusterSize.png r1 manage 6.9 K 2014-03-12 - 08:38 HaiyunTENG  
PNGpng 2010Eff.png r1 manage 6.8 K 2014-03-12 - 08:38 HaiyunTENG  
PNGpng 2010RunScanCS.png r1 manage 10.1 K 2014-03-12 - 09:02 HaiyunTENG  
PNGpng 2010RunScanEff.png r1 manage 9.0 K 2014-03-12 - 09:02 HaiyunTENG  
PNGpng 2010Theta2CS.png r1 manage 7.2 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng CSCSegmentMatch.png r1 manage 13.9 K 2014-02-22 - 20:46 HaiyunTENG segment match filter descriminate the segment from trajectory and noise
PNGpng CompareMatchLocalEve.png r1 manage 30.1 K 2014-03-12 - 08:50 HaiyunTENG  
PNGpng CompareMatchLocalOdd.png r1 manage 26.4 K 2014-03-12 - 08:50 HaiyunTENG  
PNGpng Eta1DEffV3.png r1 manage 7.3 K 2014-03-12 - 09:02 HaiyunTENG  
PNGpng Extrapolation.png r1 manage 16.8 K 2014-02-22 - 20:38 HaiyunTENG Efficiency evaluation by segement extrapolation
PNGpng MatchV1Eff1D_RE13B.png r1 manage 11.2 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng MatchV1Eff2D_RE13B.png r1 manage 31.6 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng RPCCone.png r1 manage 54.9 K 2014-02-22 - 20:48 HaiyunTENG RPC cone projection for impaction checking
PNGpng RPCCone1D_RE13B.png r1 manage 10.7 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng RPCCone2D_RE13B.png r1 manage 42.8 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng SegmentError.png r1 manage 44.7 K 2014-02-22 - 20:47 HaiyunTENG CSC measurement bias on eta direction
PNGpng SegmentLostMatch.png r1 manage 14.1 K 2014-03-12 - 09:04 HaiyunTENG  
PNGpng peak_valley_shape.png r1 manage 73.2 K 2014-03-11 - 23:25 HaiyunTENG the high-peak-low-valley shape of efficiency w.r.t incident angle
PNGpng run147755Eff1D_RE13B.png r1 manage 6.3 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng run147755Eff2D_RE13B.png r1 manage 41.6 K 2014-03-12 - 08:41 HaiyunTENG  
PNGpng simHit2RPC.png r1 manage 14.5 K 2014-02-22 - 20:39 HaiyunTENG simHit method for "MCTruth" of RPC efficiency evaluation
Edit | Attach | Watch | Print version | History: r19 | r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r11 - 2014-03-19 - HaiyunTENG
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback