RpcSandbox < Sandbox

This links to WebSearch.

%TOC%

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

 %ATTACHURL%/Extrapolation.png    %ATTACHURL%/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

<latex title="delta R">
  \Delta{R} = \sqrt{{\Delta{\eta}}^2+{\Delta{\phi}}^2}  \\
</latex>

 %ATTACHURL%/CSCSegmentMatch.png

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.

 %ATTACHURL%/RPCCone.png

---++ MC Analysis 

All MC analysis is running under CMSSW_4_1_5 with ideal globaltag. 

The efficiency caculation for singal roll:

<latex title="RPC efficiency">
  \varepsilon_{RPC} = \frac{N_{RPC}}{N_{CSC}}  \\
</latex>

<latex title="RPC efficiency error">
  \Delta{\varepsilon} = \sqrt{\frac{\varepsilon_{RPC} \times \left(1-\varepsilon_{RPC} \right)}{N_{CSC}}} \\
</latex>

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

 %ATTACHURL%/MatchV1Eff1D_RE13B.png    %ATTACHURL%/MatchV1Eff2D_RE13B.png 

Efficiency w.r.t incident angle:
 
 %ATTACHURL%/Eta1DEffV3.png

Parameters for RPC cone projection:

<latex title="RPC efficiency for whole endcap">
 ConeX = 0.01 \\
 ConeY = -0.2 \\
 \Delta{R} \le 0.2 \\
</latex>

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

 %ATTACHURL%/RPCCone1D_RE13B.png    %ATTACHURL%/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

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

run condition and globaltag:
|  run  |  HV(V)  |  Threshold(mV)  |  MagneticField(T)  |  Blacklist  |  GlobalTag  |  Lominosity(pb^-1)  |
|  146644  |  9400  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  1.132  |
|  146804  |  9400  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.5677  |
|  146944  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.5393  |
|  147114  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.5251  |
|  147115  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.4803  |
|  147217  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.2604  |
|  147219  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010+RE-1/3/C07-C18  |  GR10_P_V10::All  |  0.3080  |
|  147222  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010+RE-1/3/C07-C18  |  GR10_P_V10::All  |  0.4460  |
|  147284  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.4276  |
|  147390  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  1.092  |
|  147450  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.2049  |
|  147451  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.8991  |
|  147453  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.2182  |
|  147754  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.9831  |
|  147755  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.5153  |
|  147757  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V10::All  |  0.5281  |
|  147926  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  0.9611  |
|  147927  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  0.2539  |
|  147929  |  9500 or 9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  0.8551  |
|  148002  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  0.3720  |
|  148029  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  0.8821  |
|  148031  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  1.119  |
|  148032  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  0.2275  |
|  148862  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  3.116  |
|  148864  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  1.988  |
|  149011  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  2.449  |
|  149291  |  9550  |  220  |  3.8  |  BadRPCList2010  |  GR10_P_V11::All  |  1.982  |

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:

<latex title="RPC efficiency for whole endcap">
  \varepsilon_{Endcap} = \frac{ \sum_{roll} N_{RPC}}{\sum_{roll} N_{CSC}} \\
</latex>

<latex title="RPC efficiency for whole endcap">
  \Delta{\varepsilon_{Endcap}}= \sqrt{ \sum_{roll} { \frac{\Delta{\varepsilon}^2 \times N_{CSC}^2}{{\sum_{roll} N_{CSC}}^2} } }  \\
</latex>

The analysis result for run147755  are shown as following;

 %ATTACHURL%/run147755Eff1D_RE13B.png   %ATTACHURL%/run147755Eff2D_RE13B.png

Total efficiency and average cluster size distribution for endcap:

 %ATTACHURL%/2010Eff.png   %ATTACHURL%/2010ClusterSize.png

Efficiency and average cluster size distribution for run scanning:

 %ATTACHURL%/2010RunScanEff.png   %ATTACHURL%/2010RunScanCS.png

Efficiency w.r.t Incident angle survey:

 %ATTACHURL%/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.

 %ATTACHURL%/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 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. 
 %ATTACHURL%/CSC2CSCMatch.png
   
   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:

 %ATTACHURL%/CompareMatchLocalOdd.png    %ATTACHURL%/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.

 %ATTACHURL%/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 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.
 
 %ATTACHURL%/peak_valley_shape0.png

        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.


 %ATTACHURL%/peak_valley_shape1.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();
     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, 

 %ATTACHURL%/CS22.png

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

 %ATTACHURL%/Theta2CS22W.png

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();

%ATTACHURL%/TCS22W.png

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.

%ATTACHURL%/TCS22.png

For a double confirm on this mistake a [[%ATTACHURL%/test0.C][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.

%ATTACHURL%/CS0.png        %ATTACHURL%/CS2.png

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

%ATTACHURL%/CS2_new.png


---++ Draft and slide

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

[[%ATTACHURL%/ApprovalRPCPlots_v6.pdf][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.






-- Main.HaiyunTENG - 21 Feb 2014

Attachments

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

Account
- Log In

- Cern Search
- TWiki Search
- Google Search
Sandbox All webs

Edit
Attach

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