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:

other HV setting in 9500V runs:

RPC rolls under single gap mode in 2010 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.

Draft and slide

http://cms.cern.ch/iCMS/jsp/openfile.jsp?tp=draft&files=DN2013_013_v8.pdf[Internal Note]]

Approval Slides

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