# 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.

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

Second a pyramid/cone 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.

## 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;

Efficiency w.r.t incident angle:

Parameters for RPC cone projection:

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

## 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

castor path: /castor/cern.ch/cms/store/data/Run2010B/RPCMonitor/RAW/v1/000/Run/Number/

run condition and globaltag:

common RPC blacklist in 2010 runs:

 Roll Id RE+1R2CH11A RE+1R2CH11B RE+1R2CH11C RE+1R2CH15A RE+1R2CH15B RE+1R2CH15C RE+1R2CH25A RE+1R2CH28A RE+1R2CH28B RE+1R2CH28C RE+1R2CH29B RE+1R2CH36A RE+1R2CH36B RE+1R2CH36C RE+1R3CH04C RE+1R3CH14A RE+1R3CH14B RE+1R3CH14C RE+1R3CH19B RE+1R3CH19C RE+1R3CH25B RE+1R3CH25C RE+1R3CH33A RE+1R3CH33B RE+1R3CH33C RE+2R2CH01A RE+2R2CH01B RE+2R2CH03A RE+2R2CH03B RE+2R3CH11A RE+2R3CH11C RE+3R2CH04A RE+3R2CH04B RE+3R2CH04C RE+3R2CH31A RE+3R2CH31B RE+3R2CH31C RE+3R2CH36B RE+3R2CH36C RE+3R3CH19A RE+3R3CH19B RE+3R3CH19C RE+3R3CH24A RE+3R3CH24B RE+3R3CH30A RE+3R3CH30B RE-1R2CH31A RE-1R2CH31B RE-1R3CH10A RE-1R3CH10B RE-1R3CH10C RE-1R3CH14B RE-1R3CH14C RE-1R3CH23B RE-1R3CH23C RE-1R3CH28A RE-1R3CH28B RE-1R3CH28C RE-1R3CH31A RE-1R3CH31B RE-1R3CH31C RE-1R3CH32A RE-1R3CH32B RE-2R2CH32B RE-2R3CH32B RE-2R3CH33C RE-3R2CH31A RE-3R2CH31B RE-3R2CH31C

other HV setting in 9500V runs:

 Roll Id HV(V) Roll Id HV(V) Roll Id HV(V) RE+3R2CH24 9550 RE+3R2CH26 9550 RE+3R2CH27 9550 RE+3R2CH30 9550 RE+3R2CH31 9550 RE+3R2CH36 9550 RE+3R3CH24 9550 RE+3R3CH26 9550 RE+3R3CH27 9550 RE+3R3CH30 9550 RE+3R3CH31 9550 RE+3R3CH36 9550 RE-1R2CH31 9550 RE-1R2CH32 9550 RE-1R3CH31 9550 RE-1R3CH32 9550 RE-3R2CH05 9550 RE-3R2CH08 9550 RE-3R2CH13 9550 RE-3R2CH17 9550 RE-3R2CH18 9550 RE-3R2CH20 9550 RE-3R2CH21 9550 RE-3R2CH25 9550 RE-3R2CH27 9550 RE-3R2CH29 9550 RE-3R2CH30 9550 RE-3R2CH32 9550 RE-3R3CH05 9550 RE-3R3CH08 9550 RE-3R3CH13 9550 RE-3R3CH17 9550 RE-3R3CH18 9550 RE-3R3CH20 9550 RE-3R3CH21 9550 RE-3R3CH25 9550 RE-3R3CH27 9550 RE-3R3CH29 9550 RE-3R3CH30 9550 RE-3R3CH32 9550

RPC rolls under single gap mode in 2010 runs:

 station ring segment HV layer status rolls in SG duration RE+1 3 19 TOP Disconnected A,B,C\_Bottom all runs RE+1 3 25 TOP Disconnected A,B,C\_Bottom since run148862 RE+1 3 33 TOP Disconnected A,B,C\_Bottom all runs RE+2 2 01 TOP Disconnected A,B,C\_Bottom all runs RE+2 2 03 TOP Disconnected A,B,C\_Bottom all runs RE+2 3 11 TOP Disconnected A,B,C\_Bottom all runs RE+3 2 04 TOP Disconnected A,B,C\_Bottom all runs RE+3 2 31 TOP Disconnected A,B,C\_Bottom all runs RE+3 2 36 BOTTOM Disconnected A,B,C\_TOP all runs RE+3 3 19 TOP Disconnected A,B,C\_Bottom all runs RE+3 3 24 TOP Disconnected A,B,C\_Bottom all runs RE+3 3 30 TOP Disconnected A,B,C\_Bottom all runs RE-1 2 31 TOP Disconnected A,B,C\_Bottom all runs RE-1 3 10 BOTTOM Disconnected A,B,C\_TOP all runs RE-1 3 14 TOP Disconnected A,B,C\_Bottom all runs RE-1 3 23 TOP Disconnected A,B,C\_Bottom all runs RE-1 3 28 TOP Disconnected A,B,C\_Bottom all runs RE-1 3 31 TOP Disconnected A,B,C\_Bottom all runs RE-3 2 31 TOP Disconnected A,B,C\_Bottom all runs RE+2 3 33 TOP Disconnected A,B,C\_Bottom all runs RE+3 3 31 TOP Disconnected A,B,C\_Bottom all runs

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;

Total efficiency and average cluster size distribution for endcap:

Efficiency and average cluster size distribution for run scanning:

Efficiency w.r.t Incident angle survey:

## 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.

• 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 heavier on higher 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). Far away distance between RPC and CSC chambers will lead to low efficiency events distributed on the RPC top/bottom edge with wider area. 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:

• 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.

• 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 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". Those pass-by trajectories are marked by red color since they actually will not impact on RPC roll and thus give an inefficient count. Further more these trajectories are measured by CSC and bias involve in, .i.e the "+", "0" and "-" with their mean on theta measurement. All these cases which could impact on RPC surface are arranged by their quasi theta measurement and then sort along the RPC strip length. Note that for get an impaction on RPC surface, the trajectories from above top case(Tat) spread its segment(Cat-) into a low theta region, while the trajectories from the below bottom case(Tbb) spread its segment(Cbb+) into a high theta region, so their position in theta region get reversed.

For large theta region, which corresponds the highest theta region in the efficiency shape, there are 2 cases impact on the top part of along RPC strip length. Trajectories from center part which get “+” segment bias(Cc+) impact on the top as well as the trajectories from original top part which get trial segment bias(Ct0), and their segment impaction both bring high efficiency events. Remember that trajectories from top and above top part which get “+” segment bias(Ct+, Cat0, Cat+, not appear on plots) will pass by the RPC roll and will not bring the inefficient count. When we move into the a bit lower region, the trajectories from the below bottom case derived by CSC segment and get a positive bias (the bb+) involved. Those segments bring fake impaction on RPC and cut down the efficiency. Since the spread theta by CSC segment is just ~0.2(which could be checked on slide9&10), the fake trigger segment could not cross the whole RPC strip length and spread into the highest theta region, so the low efficiency part only appears in a less high theta region.

• 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(); Follow by the suggestion, the last few bins on such kind of histgram is merged and now a varibale bin size histgram is made.

## A mistake in the cluster size w.r.t incident angle plot

in the analysis the cluster size w.r.t incident angle result is found to be wrong. For RE+1/3/B case, the cluster size distribution is ~1.5,

but the cluster size w.r.t incident angle shows a >2 value on every bins

the problem comes from the bin range of the cluste size histograme, in my previous code I use [0,10] as the range for cluster size and set 10 bins:

TH1F* composeHistogramClusterSize = new TH1F(composeHistogramClusterSizeName[i].c_str(), composeHistogramClusterSizeName[i].c_str(), 10, 0, 10); TH2F* composeHistogramTheta2CST = new TH2F(composeHistogramTheta2CSTName[i].c_str(), composeHistogramTheta2CSTName[i].c_str(), 50, -0.5, 4.5, 10, 0, 10);

after I fill the cluster size w.r.t incident histogram, I make a projection along Y axis which is the cluster size axis:

((TH1F*)(myHistogramsClusterSize->At(index)))->Fill(ClusterSize); ((TH2F*)(myHistogramsTheta2CST->At(index)))->Fill(tan(Angle), ClusterSize);

myHistogramsTheta2CS->AddLast(new TH1F(composeHistogramTheta2CSName[index].c_str(), composeHistogramTheta2CSName[index].c_str(), 50, -0.5, 4.5));

for(int ThetaIndex0 = 1; ThetaIndex0 <= 50; ThetaIndex0++) { TH1D* SampleCST = ((TH2F*)(myHistogramsTheta2CST->At(index)))->ProjectionY("", ThetaIndex0, ThetaIndex0, "o"); double SampleCSTMean = SampleCST->GetMean(); double SampleCSTMeanError = SampleCST->GetMeanError(); ((TH1F*)(myHistogramsTheta2CS->At(index)))->SetBinContent(ThetaIndex, SampleCSTMean); ((TH1F*)(myHistogramsTheta2CS->At(index)))->SetBinError(ThetaIndex, SampleCSTMeanError); }

From the 2D histograme a projection along Y axis(cluster size axis) with all the bins could be produce, this result get a same shape of hisograme for cluster size, but a different mean value. (compare with the cluster size distribution plot above)

TH1D* SampleCST0 = ((TH2F*)(myHistogramsTheta2CST->At(index)))->ProjectionY("", 0, -1, "o"); SampleCST0->Draw();

the reason is in the filled cluster size value are just close to the bin edge, in the projection the new TH1F SampleCST will treat the content as the bin center value. so the whole histogram shift 0.5 to the right.

When I use the new bin setting as follows:

TH1F* composeHistogramClusterSize = new TH1F(composeHistogramClusterSizeName[i].c_str(), composeHistogramClusterSizeName[i].c_str(), 10, 0.5, 10.5); TH2F* composeHistogramTheta2CST = new TH2F(composeHistogramTheta2CSTName[i].c_str(), composeHistogramTheta2CSTName[i].c_str(), 50, -0.5, 4.5, 10, 0.5, 10.5);

the histgrame show a correct mean value.

For a double confirm on this mistake a test0.C file is provide, the histograme CS0 and CS2 are filled with the same events, but the CS2 shows a same shape to CS0 with different mean value.

when in test1.C , the bin range is changed and the histograme CS2 get correct mean value as CS0.

## 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
png 2010ClusterSize.png r1 manage 6.9 K 2014-03-12 - 08:38 HaiyunTENG
png 2010Eff.png r1 manage 6.8 K 2014-03-12 - 08:38 HaiyunTENG
png 2010RunScanCS.png r1 manage 10.1 K 2014-03-12 - 09:02 HaiyunTENG
png 2010RunScanEff.png r1 manage 9.0 K 2014-03-12 - 09:02 HaiyunTENG
png 2010Theta2CS.png r1 manage 7.6 K 2014-05-07 - 10:58 HaiyunTENG
pdf ApprovalRPCPlots_v6.pdf r1 manage 4731.3 K 2014-05-08 - 04:42 HaiyunTENG
png CS0.png r1 manage 4.1 K 2014-05-07 - 10:52 HaiyunTENG
png CS2.png r1 manage 4.3 K 2014-05-07 - 10:52 HaiyunTENG
png CS22.png r1 manage 6.5 K 2014-05-07 - 10:43 HaiyunTENG
png CS2_new.png r1 manage 4.1 K 2014-05-07 - 10:52 HaiyunTENG
png CSC2CSCMatch.png r1 manage 118.7 K 2014-04-08 - 02:29 HaiyunTENG
png CSCSegmentMatch.png r1 manage 13.9 K 2014-02-22 - 20:46 HaiyunTENG segment match filter descriminate the segment from trajectory and noise
png CompareMatchLocalEve.png r1 manage 30.1 K 2014-03-12 - 08:50 HaiyunTENG
png CompareMatchLocalOdd.png r1 manage 26.4 K 2014-03-12 - 08:50 HaiyunTENG
png Eta1DEffV3.png r1 manage 7.3 K 2014-03-12 - 09:02 HaiyunTENG
png Extrapolation.png r1 manage 16.8 K 2014-02-22 - 20:38 HaiyunTENG Efficiency evaluation by segement extrapolation
png MatchV1Eff1D_RE13B.png r1 manage 11.2 K 2014-03-12 - 08:41 HaiyunTENG
png MatchV1Eff2D_RE13B.png r1 manage 31.6 K 2014-03-12 - 08:41 HaiyunTENG
png RPCCone.png r1 manage 54.9 K 2014-02-22 - 20:48 HaiyunTENG RPC cone projection for impaction checking
png RPCCone1D_RE13B.png r1 manage 10.7 K 2014-03-12 - 08:41 HaiyunTENG
png RPCCone2D_RE13B.png r1 manage 42.8 K 2014-03-12 - 08:41 HaiyunTENG
pdf Rpc_eff_ana_Teng_v5.pdf r1 manage 341.0 K 2014-03-20 - 17:32 HaiyunTENG CPC draft （some fix-up on the reference）
png SegmentError.png r1 manage 44.7 K 2014-02-22 - 20:47 HaiyunTENG CSC measurement bias on eta direction
png SegmentLostMatch.png r1 manage 14.1 K 2014-03-12 - 09:04 HaiyunTENG
png TCS22.png r1 manage 10.2 K 2014-05-07 - 10:46 HaiyunTENG
png TCS22W.png r1 manage 10.3 K 2014-05-07 - 10:46 HaiyunTENG
png Theta2CS22W.png r1 manage 7.7 K 2014-05-07 - 10:43 HaiyunTENG
png 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
png peak_valley_shape0.png r1 manage 227.7 K 2014-04-08 - 02:01 HaiyunTENG
png peak_valley_shape1.png r1 manage 114.0 K 2014-04-08 - 02:01 HaiyunTENG
png run147755Eff1D_RE13B.png r1 manage 6.3 K 2014-03-12 - 08:41 HaiyunTENG
png run147755Eff2D_RE13B.png r1 manage 41.6 K 2014-03-12 - 08:41 HaiyunTENG
png simHit2RPC.png r1 manage 14.5 K 2014-02-22 - 20:39 HaiyunTENG simHit method for "MCTruth" of RPC efficiency evaluation
c test0.C r1 manage 0.5 K 2014-05-07 - 11:01 HaiyunTENG
c test1.C r1 manage 0.5 K 2014-05-07 - 11:01 HaiyunTENG
Topic revision: r19 - 2014-05-08 - HaiyunTENG

 Home Sandbox Web P View Edit Account
 Cern Search TWiki Search Google Search Sandbox All webs
Copyright &© 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