Oct 2009

Oct 15 2009

sample	A/total	B/total	C/total	D/total
Wjets	0.893066	0.0671457	0.0472416	0.0030986
Zjets	0.922181	0.0437714	0.0401662	0.00390486

Oct 9 2009

sideband method: 1 times background	counting	MC truth
number of total events under Z peak	405.01
number of observed events in the side bands	18.84
number of signal under Z peak	404.51	404.46
number of signal in the side bands	18.33	18.31
number of background under Z peak	0.50	0.56
number of background in the side bands	0.50	0.53

sideband method: 10 times background	counting	MC truth
number of total events under Z peak	410.01
number of observed events in the side bands	23.60
number of signal under Z peak	404.97	404.46
number of signal in the side bands	18.56	18.31
number of background under Z peak	5.04	5.55
number of background in the side bands	5.04	5.29

sideband method: 20 times background	counting	MC truth
number of total events under Z peak	415.56
number of observed events in the side bands	28.89
number of signal under Z peak	405.48	404.46
number of signal in the side bands	18.81	18.31
number of background under Z peak	10.08	11.11
number of background in the side bands	10.08	10.58

Zee

sideband method:	counting	MC truth
number of data events under Z peak	349.19
number of data events in the sidebands	16.54
number of signal under Z peak	348.70	348.65
number of signal in the sidebands	16.04	16.02
number of background under Z peak	0.49	0.54
number of background in the sidebands	0.49	0.52

sideband method: 10 X background	counting	MC truth
number of data under Z peak	354.06
number of data in the sidebands	21.21
number of signal under Z peak	349.12	348.65
number of signal in the sidebands	16.27	16.02
number of background under Z peak	4.94	5.41
number of background in the sidebands	4.94	5.19

sideband method: 20 X background	counting	MC truth
number of data events under Z peak	359.47
number of data events in the sidebands	26.40
number of signal under Z peak	349.59	348.65
number of signal in the sidebands	16.52	16.02
number of background under Z peak	9.89	10.82
number of background in the sidebands	9.89	10.38

Sept 2009

Sept 23 2009

Lepton selection:
e/mu SUSY 09 good + iso
pT> 20 GeV 

W selection:
exactly one lepton
tcMET > 20 GeV
- 40 GeV < transverse mass < 100 GeV

Z selection:- exactly two leptons
SF- OS
76 GeV < dilepton mass < 106 GeV
May add Z veto and jet veto etc. later..

Event weight: 1/pb

	W+0jets	Z+0jets	TTBar	QCD
channel e	4622.3	25.0	28.6	364.1
channel m	5217.6	262.0	30.8	66.2
channel ee	0.008	262.3	0.5	0
channel mm	0	303.9	0.5	0

	W+jets (alpgen)	Z+jets(alpgen)	TTBar	QCD
channel e	5894.56	47.846	28.5595	364.142
channel m	6617.21	335.144	30.7581	66.2076
channel ee	0.0311412	347.795	0.497157	0
channel mm	0	403.474	0.544422	0

*W Transverse Mass:

*Z Mass:

*tcMET:

*Number of Jets:

*Electron Pt:

*Muon Pt:

July 2009

July 02 2009

Hi Boris, sorry for bothering you. Can I ask a question about transformation matrix? we want to use the residual information of hits. But it is in the local coordinate and can not give us the information about global phi
we want to transform it to global coordinate, could you point me to the transformation matrix
you should use the toGlobal() method of the detector surface class

GlobalPoint toGlobal (const Point2DBase< Scalar, LocalTag > lp)
http://cms-service-sdtweb.web.cern.ch/cms-service-sdtweb/doxygen/CMSSW_3_1_0/doc/html/de/d10/classSurface.html

for the error, you probably have to use this jacobian
http://cmslxr.fnal.gov/lxr/source/TrackingTools/AnalyticalJacobians/interface/JacobianLocalToCartesian.h

Slava:

Get the geometry as in
http://cmslxr.fnal.gov/lxr/source/TrackPropagation/SteppingHelixPropagator/test/SteppingHelixPropagatorAnalyzer.cc#248

Once you have it and know the detId
get the GeomDet as in
http://cmslxr.fnal.gov/lxr/source/TrackPropagation/SteppingHelixPropagator/test/SteppingHelixPropagatorAnalyzer.cc#545

The surface is
http://cmslxr.fnal.gov/lxr/source/TrackPropagation/SteppingHelixPropagator/test/SteppingHelixPropagatorAnalyzer.cc#549

Conversion to global is
http://cmslxr.fnal.gov/lxr/source/TrackPropagation/SteppingHelixPropagator/test/SteppingHelixPropagatorAnalyzer.cc#554

     --slava

June 2009

30 June 2009

Residual distributions in electron sample and gamma sample:

07 June 2009

sample	W+jets	Z+jets	ttbar	LM0
single electron 0x401	5.6336498e+06	5.1697409e+05	3.9966528e+04	7.2864876e+03
single electron && Z veto 0x441	5.5776657e+06	3.8037596e+05	3.1602904e+04	5.2995895e+03
single electron && Z veto && MET 0x451	5.0926723e+06	3.5638677e+04	2.8262477e+04	5.0689375e+03
single electron && Z veto && MET && W transverse mass 0x471	4.9698547e+06	2.9071119e+04	1.8710239e+04	1.9993490e+03
single muon 0x802	7.3464874e+06	4.9731915e+05	5.1497707e+04	9.8579477e+03
single muon && Z veto 0x842	7.2827001e+06	3.5244692e+05	4.1471547e+04	7.2875808e+03
single muon && Z veto && MET 0x852	6.7619691e+06	2.7231344e+05	3.7484365e+04	6.9885438e+03
single muon && Z veto && MET && W transverse mass 0x872	6.5957841e+06	2.6070908e+05	2.5544496e+04	2.8014750e+03
two electrons 0x404	40.5	3.1654032e+05	1.5779909e+03	3.8966672e+02
two electrons && opp charge 0x604	31.5	3.0871938e+05	1.5430851e+03	3.2562678e+02
two electrons && opp charge && Z mass 0x704	4.5	2.9033522e+05	3.4986490e+02	5.9698251e+01
two muons 0x808	0	4.7857864e+05	2.5216736e+03	7.4731346e+02
two muons && opp charge 0xA08	0	4.7857498e+05	2.5168590e+03	6.3822849e+02
two muons && opp charge && Z mass 0xB08	0	4.4596033e+05	5.8457810e+02	8.9004661e+01

03 June 2009

nTuplelize the LM0 sample:

python makeCrabFiles.py -CMS2cfg SingleLeptonFilter_cfg.py -d /SUSY_LM0-sftsht/Summer08_IDEAL_V11_v1/GEN-SIM-RECO -t CMS2_V01-02-06


 python postProcessing.py -c /home/users/yanjuntu/2_2_3/CMSSW_2_2_3/crab/SUSY_LM0-sftsht_Summer08_IDEAL_V11_v1 -d /pnfs/t2.ucsd.edu/data4/cms/phedex/store/user/yanjuntu/SUSY_LM0-sftsht/CMS2_V01-02-06/cdf132380867b0b4db068f1143de6fed/ -o /data/tmp/cms2-V01-02-06/SUSY_LM0_Single-lepton
.L postProcessingMacro.C++
root [1] postProcess(110,1,1)    //110 pb

scale1fb: 0.542711

02 June 2009

total # events in Z+jets sample	763804
# gen Zee	315386
# gen Zmm	321268
# gen Ztt	127150

# gen Zee	315386
# single lepton	141382
# single lepton && Z veto	104023
# single lepton && Z veto && MET	9746
# single lepton && Z veto && MET && W transverse mass	7950

# single lepton	141382
# single lepton without additional good track	77404
second lepton with abs(eta) >2.4	59985
second lepton with abs(eta) < 2.4	17419

# gen Zmm	321268
# single lepton	136018
# single lepton && Z veto	90387
# single lepton && Z veto && MET	74473
# single lepton && Z veto && MET && W transverse mass	71292

# single lepton	136018
# single lepton without additional good track	85660
second lepton with abs(eta) >2.4	78870
second lepton with abs(eta) < 2.4	6790

May 2009

21 May

Old Looper tutorial

* go to CMS2/NtupleMacros/Tools
*make a txt file: eg. branches.txt

  float els_d0 
  float els_d0corr 
  vector < LorentzVector > * els_p4 
  float els_tk_isolation 

*in root

   .L makeCMS2ClassFiles.C++ 
   makeCMS2ClassFiles("/data/tmp/cms2-V01-02-06/TTJets-madgraph_Fall08_IDEAL_V9_v2/merged_ntuple.root", false, "branches.txt")

*3 files are created: CMS2.h, branches.h, ScanChain .C

* right now, we need to fill branches in ScanChain .C. Puneeth is going to change the macro to make those coped branched get filled automatically

* At last, run the Looper:

  .L ScanChain.C++ 
   TChain *ch = new TChain("Events")      
   ch->Add("/data/tmp/cms2-V01-02-06/TTJets-madgraph_Fall08_IDEAL_V9_v2/merged_ntuple.root") 
   ScanChain(ch) 

20 May

Fill vectors for CaloTaus in TauMaker .

19 May

Wenu Events

Wmnu Events

Zee Events

Zmm

18 May

8 May

post processing the ntuple files

python postProcessing.py -c  ~yanjuntu/2_2_3/CMSSW_2_2_3/crab/ZJets-madgraph_Fall08_IDEAL_V9_reco-v2_Single-lepton -d  /pnfs/t2.ucsd.edu/data4/cms/phedex/store/user/yanjuntu/ZJets-madgraph/CMS2_V01-02-06/88a5c6870cc62298bb13ca6e2beea94a/ -o /data/tmp/cms2-V01-02-06/ZJets-madgraph_Fall08_IDEAL_V9_v1_Single-lepton

6 May (ZW ratio)

Define 4 event types:
  1. events with 1 isolated good electron Pt >20 (will apply MET larger than certain value later)
  2. events with 1 isolated good muon Pt > 20 (will apply MET larger than certain value later)
  3. events with 2 isolated good electrons Pt >20 (will apply MET less than certain value later)
  4. events with 2 isolated good muons Pt > 20(will apply MET less than certain value later)  

Plots that I made: 
  1. lepton Pt
  2. number of jets (JPT Jets Et> 15 GeV)
  3. tcMET
  4. patMET


In W+Jets sample: 
we have 
    5.7795344e+06 type1 events 
    7.5724593e+06 type2 events. 
My question: why do we have 40% more W->mu events passing the muon cuts than W->e events passing electron cuts?
How much is the muon ID efficiency higher than electron ID efficiency? what is the geometry acceptances for electrons and muons?

April 2009

28 April (CMSSW_2_2_7)

T1->Draw("abs(ele_eta):ele_layer1_charge >> singleGamma"," ele_pt>20 &&abs(ele_eta)>1.5 && ele_loose_id==1 && ele_iso>0.92 && abs(ele_d0corr)<0.050 && abs(ele_conv_dcot)>=0.02 && abs(ele_conv_dist)>=0.02&& ele_valid_pixelhits<3 &&ele_layer1_det==2 && ele_valid_pixelhits>0", "box");

cuts	number of electrons in single electron sample	number of electrons in single gamma sample
Pt > 20 GeV &&loose ID && isolated && abs(d0) < 0.05 && current conversion removal	43089	1503
abs(eta) < =1.5	27886 (keep)	549 (keep)

abs(eta) > 1.5	15203 (detail studies)	954 (detail studies)
number of valid pixel hits >=3 number of valid pixel hits = 1 or 2 number of valid pixel hits = 0	12870 (keep) 2330 (detail studies) 3 (remove)	235 (keep) 648 (detail studies ) 71 (remove)

number of valid pixel hits = 1 or 2	2330 (detail studies)	648 (detail studies )
first valid pixel hit in: Pixel Barrel (detid =1 ) Pixel Disk (detId =2)	1541 789	194 454

number of valid pixel hits = 1 or 2	2330 (detail studies)	648 (detail studies )
first valid pixel hit in: Pixel Barrel (detid =1 )	1541	194
layer of the first valid pixel hit (Barrel): layer =1 layer =2	1365 (keep) 176 (remove)	39 (keep) 155 (remove)

number of valid pixel hits = 1 or 2	2330 (detail studies)	648 (detail studies )
first valid pixel hit in: Pixel Disk (detId =2)	789	454
Charge of the first valid pixel hit (Disk): charge <40000 (unit: electrons) charge >40000	704 (keep) 85 (remove)	119 (keep) 335 (remove)

first valid hit in	pixel barral	pixel disk	strip detector
prompt electrons (30)
conversions (14)

27 April (CMSSW_2_2_7)

17 April

cmsDriver.py QCD_Pt_30_50_cfi -s GEN:ProductionFilterSequence,SIM,DIGI,L1,DIGI2RAW,HLT -n 10 --conditions FrontierConditions_GlobalTag,IDEAL_30X::All --relval 9000,250 --datatier 'GEN-SIM-DIGI-RAW-HLTDEBUG' --eventcontent FEVTDEBUGHLT

cmsDriver.py SinglePiPt10.cfi -s GEN:ProductionFilterSequence,SIM,DIGI,L1,DIGI2RAW,HLT -n 100  --conditions FrontierConditions_GlobalTag,IDEAL_30X::All --relval 9000,250 --datatier 'GEN-SIM-DIGI-RAW-HLTDEBUG' --eventcontent FEVTDEBUGHLT
 cmsDriver.py SinglePiPt10_cfi_GEN_SIM_DIGI_L1_DIGI2RAW_HLT -s RAW2DIGI,RECO --relval 25000,100 --datatier GEN-SIM-RECO --eventcontent RECOSIM --conditions FrontierConditions_GlobalTag,IDEAL_30X::All

16 April (talk with Kevin)

I talked with both Boris and Kevin about the plan adding the number of lost hits inside the innermost valid hit and
the number of lost hits outside the outmost valid hit.

The main issue is that how we add these additional information without changing the tracks being
reconstructed.

What I learned from Boris and Kevin is that we have 6 steps in patten recognition algorithm.
Each step could have different seeding, threshold and quality cuts. We can change the
threshold in each step, e.g. maxLostHits and MaxConsecLostHits. However, changing these parameters
will change the tracking being reconstructed. So we need to figure out two things to make a more
concrete plan:
1. Figure out  how and where we add these information.
2. We need to make sure that the lost hits we added will not be taken into account by the fitter and track quality cutting.

Both Boris and Kevin need a little time to think about this. We agree that we need to make a doable plan
as soon as possible.

15 April (talk with boris about adding number of invalid hits inside and outside)

build CMSSW release 3_1_0_pre4.
Dave has installed it in uaf machine but in the different directory:

export SCRAM_ARCH=slc4_ia32_gcc345
export VO_CMS_SW_DIR=/nfs-1/code/cmslocal/
source $VO_CMS_SW_DIR/cmsset_default.sh

14 April (generating the single electron and gamma samples &Summary of the conversion studies)

Generating more events: 

cvs co -r CMSSW_2_2_7 -d Configuration CMSSW/Configuration  

mkdir GenMC  

cmsDriver.py  SingleElectronFlatPt5To100.cfi -s GEN,SIM,DIGI,L1,DIGI2RAW,HLT -n 10  --conditions FrontierConditions_GlobalTag,IDEAL_V12::All --relval 9000,250 --datatier 'GEN-SIM-DIGI-RAW-HLTDEBUG' --eventcontent FEVTDEBUGHLT  


cmsDriver.py SingleElectronFlatPt5To100_cfi_GEN_SIM_DIGI_L1_DIGI2RAW_HLT -s RAW2DIGI,RECO -n 10 --relval 25000,100 --datatier GEN-SIM-RECO --eventcontent RECOSIM --conditions FrontierConditions_GlobalTag,IDEAL_V12::All

cmsRun SingleElectronFlatPt5To100_cfi_GEN_SIM_DIGI_L1_DIGI2RAW_HLT_RAW2DIGI_RECO_IDEAL.py

first valid hit in	pixel barral	pixel disk	strip detector
prompt electrons (30)	9	21	0
conversions (14)	6	6	2

cuts	single electron sample	diGamma sample
6 GeV < Pt < 20 GeV && abs(eta) > 1.5	665	105
loose ID	529	104
rel_iso > 0.92	237	73
abs(d0) < 0.05	237	47
remove conversion pair with abs(dcot) < 0.02 && abs(dist)< 0.02	236	28

8 April ~ 10 April 2009 (Fireworks)

Add taus in display in terms of Jets+tracks
apply the following filter as a temparary solution for that tau collection is very generic. most of them are generic jets.
isolationTracks().empty()&&!signalTracks().empty()

One-prong CaloTau (found genp match)


Three-prong CaloTau (no genp match)

3 April 2009 (further investigating the electrons with number of valid pixel hits <3)

The radius of the first valid hit in pixel disk (after applying Puneeth's conversion rejection):

* singleElectron_ele_layer1_radius_convRej_loose_iso50_v1.gif:

* diGamma_ele_layer1_radius_convRej_loose_iso50_v1.gif:

The layer of the first valid hit in pixel barrel (after applying Puneeth's conversion rejection):

* singleElectron_ele_layer1_layer_convRej_loose_iso50_v1.gif:

* diGamma_ele_layer1_layer_convRej_loose_iso50_v1.gif:

I took a look at the real electrons with number of valid pixel hits <3, with the wish that we
can do something to recover them. Here is what I found:

1. I start from the bottom left plots on March 29, which is the number of valid pixel hits in real electron
sample after Puneeth's rejection. If we require n_valid_pixelhits > 3, we loose 30 out of 236 real electrons.

2. For these 30 electrons, 21 of them have the first valid hit in pixel disk and 9 of them in pixel barrel.

3. I took a look at the 9 electrons starting from barrel. They all have minimum 2 valid pixel hits (which
means that they only have one missing hit). The more important thing is that 7 out of 9  have the first valid
hit in layer 1 of the pixel barrel, and 2 out of 9 have the first valid hit in layer 2 of the pixel barrel. You can see
the plot in today's twiki entry.

It makes sense because real electron starts early.

4. Then I do same thing for digamma sample. I found that larger fraction of electrons with first valid hit in
layer 2 of the pixel barrel, 4 out of 6. see right plot in twiki.

5. For those electron with first valid hit in disk, they all start from layer 1 of the pixel disk.  Therefore
no discriminating power for them. (it makes sense because of the geometry of the disk. They are
perpendicular to the beam line.)

From point 3 and 4, I have the conclusion that if we want to recover those real electrons, on top of
number of valid pixel cut, we can further ask that:
   if the first valid hit in barrel region, is it in the layer 1?
   if it is in layer 1, identify it as real electron.
   if  not, reject it.
By doing so, we can further recover 7 electrons out of total 30, while let 2 out 14 conversions in. How do you think?

I am also thinking about what we can do with electrons starting in disk. They are a large fraction but
less discriminated using this methed so far.

March 2009

29 March 2009 (electrons passing loose ID, d0corr < 500 micro and rel iso> 0.92 )

Before applying Puneeth's conversion rejection:

* singleElectron_ele_valid_pixelhits_loose_iso50_v1.gif:

* diGamma_ele_valid_pixelhits_loose_iso50_v1.gif:

After applying Puneeth's conversion rejection:

* singleElectron_ele_valid_pixelhits_convRej_loose_iso50_v1.gif:

* diGamma_ele_valid_pixelhits_convRej_loose_iso50_v1.gif:

* Before applying Puneeth's conversion rejection:

* After applying Puneeth's conversion rejection:

electron identification:
https://twiki.cern.ch/twiki/bin/view/CMS/SWGuideCutBasedElectronID

26 March 2009 (comparing with the conversion-pair-finder algorithm)

cuts	single electron sample	diGamma sample
6 GeV < Pt < 20 GeV	2871	115
abs(eta) > 1.5	665	105
abs(d0) <0.025 (0.05)	653(663)	53(73)
remove conversion pair with abs(dcot) < 0.02 && abs(dist)< 0.02	652	20
number of valid pixel hits >2	588	12

fraction of remmoved real electrons: (665-588)/2871 = 2%
fraction of removed conversions: 100%-(12+10 central)/115 = 81%
comparing to Puneeth's numbers: ~2% and ~78%

* singleElectron_ele_valid_pixelhits_convRej_v1.gif:

* diGamma_ele_valid_pixelhits_convRej_v1.gif:

The Delta Cot(theta) and dist distributions for electrons from conversions are (Puneeth cuts at |dcot|<0.02 && |dist|<0.02):

* diGamma_ele_conv_dcot_v1.gif:

* diGamma_ele_conv_dist_v1.gif:

email Puneeth:

On Thu, Mar 26, 2009 at 2:59 PM, Yanjun Tu  wrote:
Hi Puneeth,

I found that in ConverstionMaker module. You avoid the GsfElectron to be the same as CTF track
by putting:

 if(els_trkidx_h->at(elIndex) == tkIndex) continue;

So it answers one of my questions.

In ConversionMaker module, you have the following vectors:
 produces   >   ("elsconvtkidx"   ).setBranchAlias("els_conv_tkidx"   );
 produces >   ("elsconvdcot"    ).setBranchAlias("els_conv_dcot"    );
 produces >   ("elsconvdist"    ).setBranchAlias("els_conv_dist" );

But, I find that we don't apply cuts on cms2.els_conv_dcot and cms2.els_conv_dist in selection.cc.
So I still don't know what cuts are used.

Best,
Yanjun




On Mar 26, 2009, at 10:34 AM, Yanjun Tu wrote:

Hi Puneeth,

How are you? I am looking at your talk that has been given on Jan 30th 2009 about rejecting electrons
from photon conversions. For the talk, I have the following understandings and questions:

1. The GsfElectrons used for your studies pass loose electron ID; have Pt>10; sigma(Pt) in cone of
dR = 0.3 < 5.
Could you tell me what loose electron ID cuts that have been used?  Could you explain why you use such isolation requirement : sigma(Pt) in cone of dR = 0.3 < 5?

The egamma group places successively tighter cuts on the electron and has different names for the electron that passes the ID cuts. For example, the loosest cut is the robust Id. The next loosest cut is loose Id, and then you have the tight Id. The looseId cuts that I talk about in my talk are from way back (1_6_X) and have evolved a bit, and I don't know from the top of my head what the new cuts are.

The isolation requirement was not tuned...it was just a reasonable first step.

2. You found that cutting on d0corr < 500 micron can reject about 70% of conversions.

3. Then, you study the algorithm which finds the conversion partner of the GsfElectron in  CTF track collection.
To do that, you look for the opposite charged CTF track in cone of 0.3 around the electron. You cut on
the Delta(Cot theta) and distance between two tracks.

You found that the algorithm can reject 25% of electrons from conversions with respect to d0 cut, while it rejects 2% real electrons. So the fraction of your left over electrons from conversions is (1-0.70-0.3*0.25) ~ 20%,  am I correct?

right. 
 

Besides, I found a function called conversionPartner in CORE/selection.cc, but it may not do what you described in the talk. e.g. the min_dcottheta = 5e-4 is a default cut, and you don't cut on dist there.  Am I looking at the correct function? what Delta(Cot theta) and Dist cuts that you used?
In addition, it seems that the function doesn't avoid that the CTF track is from the same GsfElectron.

I'm not sure how that function got there....it looks like dima put it in. For us, an electron whose |dist| < 0.02 && |dcot| < 0.02 is considered a conversion. I hope that helps. 

Thanks in advance for answering my questions.

Regards,
Yanjun

25 March 2009 (Gsf tracks after d0corr cut; number of valid pixel hits and the radius of the innermost valid hit)

* singleElectron_ele_layer1_radius_v1.gif:

* diGamma_ele_layer1_radius_v1.gif:

* singleElectron_ele_layer1_3D_v1.gif:

* diGamma_ele_layer1_3D_v1.gif:

* singleElectron_ele_valid_pixelhits_v1_d025.gif:

* diGamma_ele_valid_pixelhits_v1_d025.gif:

* singleElectron_ele_valid_pixelhits_v1_d050.gif:

* diGamma_ele_valid_pixelhits_v1_d050.gif:

24 March 2009 (Gsf tracks)

* singleElectron_ele_eta_v1.gif:

* diGamma_ele_eta_v1.gif:

* singleElectron_ele_pt_v1.gif:

* diGamma_ele_pt_v1.gif:

* singleElectron_ele_valid_pixelhits_v1.gif:

* diGamma_ele_valid_pixelhits_v1.gif:

* singleElectron_ele_layer1-sizerz_PXB_v1.gif:

* diGamma_ele_layer1-sizerz_PXB_v1.gif:

* singleElectron_ele_layer1-charge_PXB_v1.gif:

* diGamma_ele_layer1-charge_PXB_v1.gif:

* singleElectron_ele_layer1-sizerz_PXF_v1.gif:

* diGamma_ele_layer1-sizerz_PXF_v1.gif:

* singleElectron_ele_layer1-charge_PXF_v1.gif:

* diGamma_ele_layer1-charge_PXF_v1.gif:

19 March 2009 (CTF tracks)

make the plots of new track variables for real electrons and electrons from conversions:

* singleElectron_track_eta.gif:

* diGamma_track_eta.gif:

* singleElectron_track_pt.gif:

* diGamma_track_pt.gif:

* singleElectron_track_valid_pixelhits.gif:

* diGamma_track_valid_pixelhits.gif:

* singleElectron_track_layer1-sizerz.gif:

* diGamma_track_layer1-sizerz.gif:

* singleElectron_track_layer1-charge.gif:

* diGamma_track_layer1-charge.gif:

11 March 2009 (copy the files from the dCache)

The options for coping the file:

1. copy the file from the dCache on the local machines using dccp.
/opt/d-cache/dcap/bin/dccp dcap://dcap-2.t2.ucsd.edu:22138/pnfs/t2.ucsd.edu/data3/cms/phedex/store/..

2. copy the file from the dCache on the remote machines using srmcp.
for srmcp you need a proxy started and the "grid user interface environment" sources on the uaf here in ucsd that means
source /code/osgcode/ucsdt2/gLite/etc/profile.d/grid_env.sh
voms-proxy-init -valid 120:00 --voms cms

3. through the webpage interface.
https://cmsweb.cern.ch/filemover/

To translate the logical file name to the physical file name:
1. http://cmsweb.cern.ch/phedex/datasvc/xml/prod/lfn2pfn?node=T2_IT_Legnaro&protocol=srmv2&lfn=/store/bla.root

2. [yanjuntu@cmslpc10 src]$ EdmFileUtil -d /store/relval/CMSSW_2_1_12/RelValDiGammaPt20_100/GEN-SIM-DIGI-RAW-HLTDEBUG-RECO/IDEAL_V9_v1/0029/362F09FF-D9AB-DD11-9D3E-00304875A9D1.root dcap://cmsdca.fnal.gov:24125/pnfs/fnal.gov/usr/cms/WAX/11/store/relval/CMSSW_2_1_12/RelValDiGammaPt20_100/GEN-SIM-DIGI-RAW-HLTDEBUG-RECO/IDEAL_V9_v1/0029/362F09FF-D9AB-DD11-9D3E-00304875A9D1.root

srmcp -2 srm://cmssrm.fnal.gov:8443/11/store/relval/CMSSW_2_1_12/RelValDiGammaPt20_100/GEN-SIM-DIGI-RAW-HLTDEBUG-RECO/IDEAL_V9_v1/0029/362F09FF-D9AB-DD11-9D3E-00304875A9D1.root file:////tmp/RelValDiGammaPt20_100/GEN-SIM-DIGI-RAW-HLTDEBUG-RECO/IDEAL_V9_v1/0029/362F09FF-D9AB-DD11-9D3E-00304875A9D1-yanjun-cp.root

10 March 2009

* track_d0_phi.gif:

* track_sizerphi_pt.gif:

* track_sizerz_eta.gif:

• track_pt.gif:
  

• track_phi.gif:
  

• track_eta.gif:
  

• track_d0.gif:
  

• track_ch2_ndof.gif:
  

• track_nvalidhits.gif:
  

• track_nlosthits.gif:
  

• sizerz_eta_pt5.gif:
  

• sizerphi_pt.gif:
  

7, 8, 9 March 2009 (First set of plots for the track ID project)

* sizerz_ntuple.gif:

• sizerphi_ntuple.gif:
  

• charge_ntuple.gif:
  

• ninner_ntuple.gif:
  

• nouter_ntuple.gif:
  

• ninner_looper.gif:
  

1. make the ntuple.
2. post processing ntuple: drop some useless information in the events and add weight to the sample. need postProcessingMacro.C
3. create CMS2.h file

root [0] gSystem->SetAclicMode(TSystem::kDebug)
root [1] .x setup.C
root [2] .L makeCMS2ClassFiles.C++
makeCMS2ClassFiles("ntuple.root")

4. specify the sample that I want to loop over:
making changes in Sample.h, Sample.cc and ConfigAndRun.h

If I don't run post-processing, I could got the following error.

/home/users/yanjuntu/CMSSW_2_2_3/src/CMS2/NtupleMacros/Tools/LooperBase.cc:29: error: 'class CMS2' has no member named 'evt_scale1fb'
/home/users/yanjuntu/CMSSW_2_2_3/src/CMS2/NtupleMacros/Tools/LooperBase.cc: In member function `virtual uint64 LooperBase::Loop()':
/home/users/yanjuntu/CMSSW_2_2_3/src/CMS2/NtupleMacros/Tools/LooperBase.cc:89: error: 'class CMS2' has no member named 'evt_nEvts'
/home/users/yanjuntu/CMSSW_2_2_3/src/CMS2/NtupleMacros/Tools/LooperBase.cc:89: error: 'class CMS2' has no member named 'evt_scale1fb'
/home/users/yanjuntu/CMSSW_2_2_3/src/CMS2/NtupleMacros/Tools/LooperBase.cc:90: error: 'class CMS2' has no member named 'evt_nEvts' 

6 March 2009

answers from Boris and Gavril A. Giurgiu <ggiurgiu@pha.jhu.edu>

The charge is measured in ADC counts and then the ADC counts are
transformed into electrons. The transformation from ADC to electrons goes
like this:

Charge(electrons) = 65.5 * VCAL - 414
where: VCAL = ( Charge(ADC) - pedestal ) * gain
So, the final transformation:
Charge(electrons) = 65.5 * ( Charge(ADC) - pedestal ) * gain - 414
Pedestal and gain are measured for each pixels. Typical numbers for
barrel are:
gain ~ 3.3 (with an RMS of 0.7)
pedestal ~ 52.6 (with an RMS of 22.0).
The charge in electrons has a distribution which peaks at ~20000 electrons
(=20ke) and has a very long tail.
The minimum cluster charge is ~5000 electrons (at least in the latest
CMSSW versions).

Your charge numbers are: 35221, 34383, 80533, so I think they
are given in electrons.

The strip charge in your second table seems to be in ADC counts. I think
ADC counts go from 0 to 256 or so...


2.
I think that your pixel cluster look like this one:

+
+-+
+
+

where: + symbol is a fired pixel cell
            - symbol is a not-fired pixel cell.

2, 3 & 4 March 2009 (Table: Hits in one track)

Studying one track in a event to make sure the code is doing what I want:
Number of valid tracker hits: 14; number of layers inside: 0; number of layers outside: 1

valid Hit	Pixel hit	detid	layer	charge	sizeX	sizeY	size (number of pixels)
0	yes	1	1	35221	1	1	1
1	yes	1	2	34382	2	4	5
2	yes	1	3	80533	3	4	5

valid Hit	strip hit	detid	layer	charge	size (number of strips)	weighted size
3	side==0(mono)	3 TIB	1	207	3	0.42
4	side==1(stereo)	3	1	246	2	0.32
5	side==1(stereo)	3	2	159	1	0
6	side==0 (mono)	3	2	175	3	0.57
7	side==0 (mono)	3	3	24	3	1.04
8	side==0 (mono)	4 TID	1	87	1	0
9	side==0 (mono)	5 TOB	1	33	2	1.98
10	side==0 (mono)	6 TEC	1	176	2	0.23
11	side==0 (mono)	6	2	223	2	0.23
.....................

Adding lines in TrackMaker.cc in NtupleMaker, so we can get the following information in our Ntuple:
1. how many layers inside the innermost valid hit? how many layers outside the outmost valid hit?
2. size of the cluster (pixel or mono strip & stereo strip) in the first 3 layers.
The coding problems I got during the study:

1. I need to dynamically cast the trackingRecHit into either SiPixelRecHit or SiStripRecHit2D:
  const SiPixelRecHit *pixel_hit_cast = dynamic_cast(&(**ihit));
  const SiStripRecHit2D *strip_hit_cast = dynamic_cast(&(**ihit));

 Pay attention to two **: ihit is the type of SiStripRecHit2D_iterator, which is an iterator over 
 a vector of reference to TrackingRecHit in the same collection. 

2. the type of the cluster() in the SiStripRecHit2D class is the edm persistent reference:

 typedef edm::Ref < edmNew::DetSetVector < SiStripCluster >,SiStripCluster  > ClusterRef;
 typedef edm::Ref < edmNew::DetSetVector < SiPixelCluster >, SiPixelCluster > pixel_ClusterRef;
 
  ClusterRef const& cluster = strip_hit_cast->cluster();
  pixel_ClusterRef const& pixel_cluster = pixel_hit_cast->cluster();

Learned something about catching exceptions when running the code:

https://twiki.cern.ch/twiki/bin/view/CMS/SWGuideEdmExceptionUse

February 2009

27 February 2009 (Talking with Kevin)

talked with Kevin, minutes:
1. thanks for pointing us to the method of getting the charge deposition information 
of a cluster. 
2. In addition to the charge, we are very interested in the size of the cluster. 
    In terms of the size of the cluster, we like to know two things:
    for strip detector
    a. number of strips.
    Kevin agrees that the size of the vector "amplitudes_"  would give us number of strips information. 
    b. the charge weighted size. 
    The method may not exist.
    We could calculated using the formula sqrt[(p_1-p_0)*q_1+(p_2-p_0)*q_2+....)/Q], 
    where p_i is the position of the ith strip and q_i is the charge , p0 is the position of central strip and Q 
   is the total charge. 
    for pixel detector. 
    a. number of pixels 
    In SiPixelCluster class, there are 3 methods: Size(), SizeX(), SizeY(). 
    My guess is Size() ! = SizeX()+SizeY(); because the pixels in the same row (column) are combined such they can
    get a two- dimensional array. 
    Kevin is not quite sure about this. We need to confirm.   
    Kevin suggests me to take a look at the analysis and DAQ codes to learn from there how they apply the methods.
    http://cmslxr.fnal.gov/lxr/source/AnalysisDataFormats/SiStripClusterInfo/interface/SiStripClusterInfo.h
    http://cmslxr.fnal.gov/lxr/source/DQM/SiPixelMonitorCluster/src/SiPixelClusterModule.cc#477  
    b. the charge weighted size. 

download xmeeting and register at http://www.es.net/

26 February 2009 (Submitting jobs to CRAB)

question: why I got the error when I submitted the jobs to the CRAB.

answer: I have to use the client version 2.4.4 for server, instead of 2.4.3

[1601] yanjuntu@uaf-3 ~/CMSSW_2_2_3/src/yanjun/Tools/CRAB$ crab -submit -c crab_0_090224_155903
crab. crab (version 2.4.3) running on Tue Feb 24 16:02:00 2009

crab. Working options:
scheduler           glite
job type            CMSSW
working directory   /home/users/yanjuntu/CMSSW_2_2_3/src/yanjun/Tools/CRAB/crab_0_090224_155903/

crab. Registering credential to the server
crab. Registering a valid proxy to the server:
crab. Credential successfully delegated to the server.

crab. Starting sending the project to the storage dot1-prod-2.ba.infn.it...

crab: Error You are using a wrong client version for server: dot1-prod-2.ba.infn.it
       For further informations about "Servers available for users" please check here:
      https://twiki.cern.ch/twiki/bin/view/CMS/CrabServer#Server_available_for_users

crab. Log-file is /home/users/yanjuntu/CMSSW_2_2_3/src/yanjun/Tools/CRAB/crab_0_090224_155903/log/crab.log

25 February 2009

found that the classes in which we could find the topological information of clusters are:

CMSSW/ DataFormats/ SiPixelCluster/ interface/ SiPixelCluster.h and
CMSSW/ DataFormats/ SiStripCluster/ interface/ SiStripCluster.h

understood the layout of the CMS silicon strip detector. The size of cluster in the rz view could only come from the information of stereo modules, which are in the angle of 100 mrad with respect with standard modules.

24 February 2009

downloaded FireWorks (cmsShow) and took a look at a cosmic event:

  wget http://cern.ch/cms-sdt/fireworks/cmsShow22.tar.gz
  tar xzf cmsShow22.tar.gz
  cd cmsShow22
  ./cmsShow -c cosmics.fwc cosmics.root
  make
  the file extractCMSDataFormats.pl is missing!
Made a simple proxy builder: 
src/Fireworks/Macros/makeProxyBuilder
Took a look at the file being made:
/src/Fireworks/User/plugins/FWTaus3DProxyBuilder.cc

23 February 2009 (Plan on the project of improving the track ID)

Three tasks to do regarding HitPattern:
1. answer: how many layers are expected inside the innermost valid hits and how 
    many layers are expected outside the outermost valid hits?
2.  define a variable Delta(ClusterSize(r,phi) - ClusterSize(r,z)).
     compare the Delta in real electron samples (Z or electron gun) with  the 
     conversion electron sample made by Puneeth
3. figure out how we deal with the residual information. 

need patches to run NtupleMaker
./CMS2/Configuration/patchesToSource.sh.223PAT

22 February 2009

Vectors to be added in the CMS2 TrackMaker:

//declare a vector of vectors to store hitPattern, the hitPattern of one hit has 11 bits
std::auto_ptr<vector<vector< uint32_t > > > vector_trks_hitPattern (new vector<vector< uint32_t> >);
std::auto_ptr<vector<vector< double > > > vector_trks_residualX (new vector<vector > );
std::auto_ptr<vector<vector< double > > > vector_trks_residualY (new vector<vector > );

keys: hitPattern is an array with 25 elements and each element is a 32-bit integer (therefore, each element doesn't correspond to a hit). It is better to store hitPattern in a vector hitPattern_cms2 such that each component of hitPattern_cms2 corresponds to a hit.

// Given a track, here is an example usage of hit pattern
// hit pattern of the track
const reco::HitPattern& p = track->hitPattern();
// loop over the hits of the track
vector< uint32_t> hitPattern_cms2;
vector< double> residualX_cms2;
vector< double> residualY_cms2;
for (int i=0; i<p.numberOfHits(); i++) {
uint32_t hit = p.getHitPattern(i);
hitPattern_cms2.push_back(hit);
residualX_cms2.push_back(track->residualX(i));
residualY_cms2.push_back(track->residualY(i));
}
vector_trks_hitPattern->push_back(hitPattern_cms2);
vector_trks_residualX->push_back(residualX_cms2);
vector_trks_residualY->push_back(residualY_cms2);

Vectors existing in the CMS2 TrackMaker:

std::auto_ptr<vector > vector_trks_trk_p4 (new vector );
std::auto_ptr<vector > vector_trks_vertex_p4 (new vector );
std::auto_ptr<vector > vector_trks_d0 (new vector );
std::auto_ptr<vector > vector_trks_d0corr (new vector );
std::auto_ptr<vector > vector_trks_z0 (new vector );
std::auto_ptr<vector > vector_trks_z0corr (new vector );
std::auto_ptr<vector > vector_trks_vertexphi (new vector );
std::auto_ptr<vector > vector_trks_chi2 (new vector );
std::auto_ptr<vector > vector_trks_ndof (new vector );
std::auto_ptr<vector > vector_trks_validHits (new vector );
std::auto_ptr<vector > vector_trks_lostHits (new vector );
std::auto_ptr<vector > vector_trks_d0Err (new vector );
std::auto_ptr<vector > vector_trks_z0Err (new vector );
std::auto_ptr<vector > vector_trks_ptErr (new vector );
std::auto_ptr<vector > vector_trks_etaErr (new vector );
std::auto_ptr<vector > vector_trks_phiErr (new vector );
std::auto_ptr<vector > vector_trks_charge (new vector );
std::auto_ptr<vector > vector_trks_outerPhi (new vector );
std::auto_ptr<vector > vector_trks_outerEta (new vector );
std::auto_ptr<vector > vector_trks_outerEt (new vector );
std::auto_ptr<vector > vector_trks_tkIso (new vector );

20 February 2009

Learned about the construction structure of CMS2 . 
The basic files helpful for developing my own loopers are: 
NtupleMacros/CORE/CMS2.h (cc)
NtupleMacros/CORE/selections.h (cc)
Templates/Looper.h(cc)
Tools/Sample.h(cc)   //the way to access our Ntuples
Tools/NMinus1Hist.cc

Learned about CMS tracker:
pixel det: 3 layers at 4 cm, 7 cm and 11 cm; 65 million pixels.
silicon strip det: 10 layers; 4 inner barrel; 6 outer barrel (2 double- sided, 4 single-sided) ; endcaps (2 inner, 2 outer);
                            10 million detector strips read by 80,000 microelectronic chips. 

19 February 2009

Learned how to submit jobs to the Grid.
CRAB Setup:

source /code/osgcode/ucsdt2/gLite/etc/profile.d/grid_env.sh
voms-proxy-init -voms cms
source /code/osgcode/ucsdt2/Crab/etc/crab.sh

CRAB example config file: https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookRunningGrid

Investigating on the topics that I could work on:

1. measure the trigger efficiency and the related CMS notes: trigger_note.txt: trigger_note.txt
2. measure the lepton ID scale factors.
3. measure the lepton fake rates.
4. study the conversion removal.
5. study the cosmic ray rejection.
6. measure the cross sections of the SM processes, e.g. Drell Yan to tautau
7. study the jet energy scale

**add tau block in our NTuple
** add taus in the Event Display

18 February 2009

*wrote the piece of code for selecting isolated muons and isolated tracks:
  * muon id: 
                  type == 14 global muons only
                  pt  > 10 GeV
                  d0 <  0.2 cm
                  chi2_over_ndof_gfit <= 10
                  nvalidHits_gfit  >=11
                  rel_iso >0.92
 
  * track id: 
                  pt  > 10 GeV
                  d0 <  0.2 cm
                  chi2_over_ndof <= 10
                  nvalidHits >=11
                  track_iso >0.90   (my definition of track_iso = pt_trk/(pt_trk+SumPt_trkaround)); cone : 0.01 -0.5

*found DYtautau reco MC samples in DBS:
  /store/mc/Summer08/Ztautau_M20/
 
*made the ditau mass though the isolated muons and isolated tracks:
  Run on 10000 DYtautau MC events: 3400 generated muons
                                          2787 reconstructed muons
                                          663   identified muons
number of events with identified muons + isolated tracks =  156
the plot is the following:
 * Ztt_ditau_muon_trk.gif: 

     

13 February 2009

Made ditau mass distribution using CaloTau or PFTau reconstructed in the Z->tautau MC 
sample that I generated yesterday (100 events). 

* Ztt_ditau_calo.gif:

• Ztt_ditau_pf.gif:
  

12 February 2009

Generated 100 Z->tautau MC events. The detector simulation takes 2.5 hours on uaf.
Looked at the caloTau collection and found ~1200 caloReco Taus there. Obviously, most of them are not real taus. 
There are only 6 reconstructed muons in the sample. 

11 February 2009

* validHits distribution of reconstructed muon candidate:

Localize the problem that I got yesterday. I got the warning of execution failure when I run my code to make the plots for muons:

%MSG-w ScheduleExecutionFailure:  PostModule 11-Feb-2009 10:12:11 PST  Run: 1 Event: 50
an exception occurred and all paths for the event are being skipped: 
---- ScheduleExecutionFailure BEGIN
ProcessingStopped
---- InvalidReference BEGIN
BadRefCore Attempt to dereference a RefCore containing an invalid
ProductID has been detected. Please modify the calling
code to test validity before dereferencing.
cms::Exception going through module YanjunAnalyzer/demo run: 1 event: 50
---- InvalidReference END
Exception going through path p
---- ScheduleExecutionFailure END

The problem is caused by the fact that some of the muons don't have innerTracks (they are standlone muons), but in my code tried to access it:

 
const TrackRef siTrack       = m->innerTrack();
cout<<"muon d0   "<<  siTrack->d0();

Solution:

float d0 = siTrack.isNonnull()  ?  siTrack->d0() : -999 ; 

debugging:
gdb cmsRun
b 'TFileAdaptor::TFileAdaptor(TFileAdaptorParams const&)' 

run  myRECO081_onlyCkf.cfg
b rfio_HsmIf_open
b getDefaultForGlobal
b stage_get
b 'castor::client::BaseClient::setOption(stage_options*)' 

09 February 2009 & 10 February 2009

Start to summarize the useful Reco variables and the way to access:

1. Electron:

float ele->caloEnergy()

float ele->eSuperClusterOverP()

float ele->eSeedClusterOverPout()

float ele->deltaEtaSuperClusterTrackAtVtx()

float ele->deltaEtaSeedClusterTrackAtCalo()

float ele->deltaPhiSuperClusterTrackAtVtx()

float ele->deltaPhiSeedClusterTrackAtCalo()

float ele->hadronicOverEm()

float ele->caloEnergyError()

float ele->trackMomentumError()

bool ele->isEnergyScaleCorrected()

bool ele->isMomentumCorrected()

bool ele->isElectron()

int ele->classification()

int ele->caloPosition()

int ele->numberOfClusters()

math::XYZVector ele->trackMomentumAtVtx()

math::XYZVector ele->TrackPositionAtVtx()

math::XYZVector ele->trackMomentumAtCalo()

math::XYZVector ele->trackMomentumOut()

math::XYZVector ele->TrackPositionAtCalo()

math::XYZPoint ele->caloPosition()

2. Track

bool track->innerOk()

double track->outerEta()

bool track->outerOk()

double track->outerP()

double track->outerPhi()

double track->outerPt()

double track->outerPx()

double track->outerPy()

double track->outerPz()

3. Muon:

accessor (v2_1_x)

muo->innerTrack()->d0()

muo->innerTrack()->z0()

muo->innerTrack()->chi2()

muo->innerTrack()->ndof()

muo->innerTrack()->numberOfValidHits()

muo->charge()

muo->calEnergy().em

muo->calEnergy().had

muo->type()

muo->globalTrack()->d0()

muo->globalTrack()->z0()

muo->globalTrack()->chi2()

muo->globalTrack()->ndof()

muo->globalTrack()->numberOfValidHits()

muo-> isolationR03()

muo->isolationR05()

muo->time()

muo->isMatchesValid()

float muo->caloCompatibility()

float muo->segmentCompatibility()

int muo->numberOfChambers()const{

Reco

Object	edm::InputTag (v2_1_x)	edm::InputTag (v1_6_x)
Track	generalTracks
Jet
Muon	muons ?
Electron	pixelMatchGsfElectron?
MET	TCMET
Photon	test
Vertex	test

PAT

Object	edm::InputTag
Track
Jet	selectedLayer1Jets*
Muon	selectedLayer1Muons*
Electron	selectedLayer1Electrons*
MET
Photon
Vertex

06 February 2009

Check out the newest version of CMS2 NtupleMaker 
cvs co -d CMS2/NtupleMaker -r V01-02-05 UserCode/JRibnik/CMS2/NtupleMaker

Learned from there how to access the collection of the reconstructed particles by the name and the label. 
However, since there are several collections for the same objects,e.g. for electrons, we have GsfElectron and Electron. 
Even in the same collection, the label names are diffirent: pixelMatchGsfElectrons, pixelMatchGsfFit etc.
It costs time to figure out what are differences. 


 

05 February 2009 (Making EDM analyzer)

Write a very basic Analyzer, which opens the reconstructed Higgs MC sample, loops over the GenParticleCollection and 
count the number of higgs decaying into muons with |eta| < 2.4. 
This simple Analyzer includes 3 files: .h, .cc, .py file
I have attached them here as the templates for future use. 

.h file .cc file .py file

Also, two useful links:
- code browser (lxr):    http://cmslxr.fnal.gov/lxr/
- cvs browser: http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/

04 February 2009

Run full detector simulation on 100 Higgs events, generated yesterday, timing: 235 seconds on UAF;  total size: 3.5 MB
*key words: 
  *the vertex smearing added
  *zero-pileup mode - simulated by MixingModule, in future may add pileup events by configuring MixingModle to low 
   luminosity or high luminosity mode
  * possible (mis)alignment scenario - FakeConditions available at the moment 
  *OSCAR producer

Perform reconstruction. size of the output 24 MB 
*key words
 *turning off trigger emulation
 *calibrations
 *Data Tier: Reco and AOD
 *sequence: local recon, global recon, high level recon

 *trick
  *cmsDriver.py sim_dig --filein=file:pythiaH190ZZ4mu.root  -s SIM,DIGI,L1,DIGI2RAW,HLT -n 100 --eventcontent FEVTSIM --conditions FrontierConditions_GlobalTag,IDEAL_V5::All  --datatier 'HLT' --no_exec
  *cmsDriver.py reco --filein=file:sim_dig_SIM_DIGI_L1_DIGI2RAW_HLT.root  -s RAW2DIGI,RECO -n 100 --eventcontent FEVTSIM --conditions FrontierConditions_GlobalTag,IDEAL_V5::All  --datatier 'RECO' --no_exe

Prepare for analyzation

build PhysicsTools, where the PAT StartKit can be found. 

03 February 2009 (generating private MC samples)

task: produce Z->tautau ntuple sample (with electron and muon triggers applied) and make dilepton mass distributions. https://twiki.cern.ch/twiki/bin/view/Main/PrivateMCProduction steps:

----
1. PYTHIA generated sample (GEN), 10,000 events. (10 TeV)  

Size : 10,000*1.75 MB/event (RAW+RECO) ~20 GB; 
electrons (or muons) from tau carry 1/3 energy of the tau, in average, 15 GeV.

https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookGeneration

First exercise 
 * check out Configuration, SimGeneral and PhysicsTools packages.

* GenH190ZZ4muExample_cfg.py.txt: GenH190ZZ4muExample _cfg.py.txt

 * use the example under Configuration/Examples/python to generate 100 Higgs->ZZ->4mu
events (10 TeV).  Size: 143 K
 * use the tool under PhysicsTools/HepMCCandAlgos/test to look at the events at generator level. 
see the distributions below:

* HZZ4mu_gen.gif:

2. Detector simulation (SIM+DIGI). 

• sim_dig_SIM_DIGI_L1_DIGI2RAW_HLT_IDEAL.py.txt: sim_dig_SIM_DIGI_L1_DIGI2RAW_HLT_IDEAL.py.txt

   
3. Reconstruction (Reco format and AOD format)

* reco_RAW2DIGI_RECO_IDEAL.py.txt: reco_RAW2DIGI_RECO_IDEAL.py.txt

4. Running EDAnalyzer (making electron and muon selection modules.)

using C++ to write the analysis code (find the existing codes); 
creating configuration files (Python); tracer to watch.
Pt and Et thresholds > 10 GeV?

https://twiki.cern.ch/twiki/bin/view/CMS/WorkBookWriteFrameworkModule

5. NTuplization. 

6. CMS2 looper. 

-- YanjunTu - 03 Feb 2009

• HZ4mu_gen.eps: HZ4mu_gen.eps

• YanjunAnalyzer.h: YanjunAnalyzer .h

• YanjunAnalyzer.cc: YanjunAnalyzer .cc

• yanjunanalyzer_cfg.py.txt: yanjunanalyzer_cfg.py.txt

• YanjunAnalyzer.cc: YanjunAnalyzer .cc