# Difference: KurtJungNotes (1 vs. 34)

#### Revision 342017-08-28 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## March 2, 2017

Line: 8 to 8

• Purdue (alternate): gsiftp://cms-gridftp.rcac.purdue.edu/store/user/kjung (for use with the new 'gfal' tools)

>
>
• MIT (alternate): gsiftp://se01.cmsaf.mit.edu:2811//cms/store/user/

• LLR: srm://polgrid4.in2p3.fr:8446/srm/managerv2?SFN=/dpm/in2p3.fr/home/cms/trivcat/store/user/
• CERN EOS: srm://srm-eoscms.cern.ch:8443/srm/v2/server?SFN=/eos/cms/store

#### Revision 332017-03-02 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## March 2, 2017

Direct srm paths for various T2 sites

• Purdue: srm://srm.rcac.purdue.edu:8443/srm/v2/server?SFN=/mnt/hadoop/store/user/kjung (soon to be decommissioned)
• Purdue (alternate): gsiftp://cms-gridftp.rcac.purdue.edu/store/user/kjung (for use with the new 'gfal' tools)

• LLR: srm://polgrid4.in2p3.fr:8446/srm/managerv2?SFN=/dpm/in2p3.fr/home/cms/trivcat/store/user/
• CERN EOS: srm://srm-eoscms.cern.ch:8443/srm/v2/server?SFN=/eos/cms/store

The gfal-* commands can be used with these paths as well as xrdcp, and the old-school lcg-cp commands via "lcg-cp -b -v -n 5 -D srmv2 "

Copying locally can be done by using "file:////" as a source or destination

## Aug. 15, 2016

tdr_diff instructions, here: tdrDiffInstr

#### Revision 322016-12-06 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## Aug. 15, 2016

Line: 10 to 10

 srmrmdir -recursive=true "srm://srm.rcac.purdue.edu:8443/srm/v2/server?SFN=/mnt/hadoop/..."
>
>
or, using the new gfal tools

 gfal-rm -r "srm://srm.rcac.purdue.edu:8443/srm/v2/server?SFN=/mnt..."

## May 29, 2014

#### Revision 312016-08-15 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## Aug. 15, 2016

tdr_diff instructions, here: tdrDiffInstr

## Feb. 1, 2016

Recursive remove from a hadoop space for CMS:

#### Revision 302016-02-01 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## Feb. 1, 2016

Recursive remove from a hadoop space for CMS:

 srmrmdir -recursive=true "srm://srm.rcac.purdue.edu:8443/srm/v2/server?SFN=/mnt/hadoop/..."

## May 29, 2014

### Post-QM Code Documentation

#### Revision 292014-05-29 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 29, 2014

### Post-QM Code Documentation

 Type Name Location(s) Notes MC Gen Pythia Generator with/without neutrinos [Purdue] /home/jung68/NoNuGen/CMSSW_5_3_15/src Produces Gen-Only test files with and without including neutrinos in the gen-jet definition MC Gen Pythia Bare-Bones Generator [Purdue] /home/jung68/PythiaGen/CMSSW_5_3_11/src Produces Gen-Only Pythia MC for testing tune cfgs MC Gen pPb Embedding Creation [Purdue] /home/jung68/CMSSW_5_3_15/src/PbpGen Produces RECO pPb MC embedded files Forest Producer Forest Unofficial embedded MC [MIT] /net/hidsk0001/d00/scratch/kjung/PbpJECs Spits out forest files using condor at MIT from existing embedded RECO files Forest Producer CVS-style forest with b-tagging info [Purdue] /home/jung68/btagForest/CMSSW_5_3_8_HI Older-style forest with working b-tagger implementation on all jet collections Forest Producer Git-style forest without b-tag info [Purdue] /home/jung68/gitForest/CMSSW_5_3_15 New-style forest to be updated with b-tagger info Analysis pPb B-Tag nTuple Creator [Purdue] /home/jung68/scratch/macros/bTagging/subscripts Creates b-tagged ntuples from forest files Analysis b-jet purity and eff. fitter [Purdue] /home/jung68/scratch/macros/bTagging/bfractionVsJetPtPP.C Creates small TH1D's from analysis ntuples for b-jet spectra creation Utility LumiCalc Setup [Purdue] /home/jung68/lumiCalc/CMSSW_5_3_9/src Simply cmsenv this directory and then use lumiCalc2.py via examples here Utility Duplicate Forest File Checker [Purdue] /home/jung68/scratch/utils/duplicateForestCheck.C Checks for duplicate forest files in collection from filelist Utility Check Forest Files for pPb or Pbp [Purdue] /home/jung68/scratch/utils/findForestRun.C Creates a new filelist of just Pbp files from an overall collection Utility Forest File Merger [MIT] /net/hidsk0001/d00/scratch/kjung/FileMerger/carefulMergeBatch.pl Carefully merges lists of forest files 100 at a time so as to not break the hadoop disk

## November 25, 2013

### pPb OpenHF + BTag Forest Production

#### Revision 282013-11-25 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## November 25, 2013

### pPb OpenHF + BTag Forest Production

Found some duplicates in the production of the OpenHF + B-Tagging HiForest that Wei created. I wrote a quick checkDuplicates script to figure out which files were duplicates - it relies on the jobs having the same job id in the output directory. The code is here:

## April 11, 2013

Some additional caveats for the b-fraction calculation (first step):

#### Revision 272013-04-11 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## April 11, 2013

Some additional caveats for the b-fraction calculation (first step):

(1) Note that for the pp samples, the standard reconstruction sequence does not include neutrinos as part of the genJet definition. Since the b-jets have a greater likelihood of stemming from a neutrino jet, this will cause an unbalance in the reconstruction efficiency of the b-jets as opposed to the inclusive jets. Furthermore, neutrinos ARE included (by accident) in the PbPb genJet definition so this correction becomes even more imperative. You can see in AN2012_126 (b-fraction calculation in PbPb and pp, 2012) that once the correction is applied, the Jet Energy Scales again match.

(2) Perhaps more importantly is a small caveat involving the regional tracking. The way the standard HI reconstruction procedure is done, the jet energies are evaluated before the regional tracking is run. This is because in order to define the regions over which to run the regional tracking, you have to know where the jets are (kind of a catch-22). Therefore, the secondary tracks are generally not included in the b-jet energies and generally are included in the non-bjet energies, due to the nature of the tracking reconstruction algorithm. Because the b-jet secondary tracks are often far from the primary vertex, these are usually ignored in the first round of tracking due to computing constraints. Therefore, the energy found wtihin b-jets is deficient as compared to inclusive jets, so the jet energy corrections applied to all jets will not completely correct the b-jets. An additional correction is needed to restore the energy lost by ignoring the regional tracks. In fact, this is akin to sliding the bjet pt spectrum (dN/dpT) to the left (or, equivalently, cutting on higher pt for the b-jets than the inclusive jets). This amounts to a b-jet number deficiency, then, that is equal to , where x is the amount deficient the b-jets are in energy (usually ~10%) and is the exponent of the falling pT spectrum (usually ~5.8). Therefore, we can say that our b-jet fraction will be off by 0.9^4.8 ~ 0.6. This also needs to be corrected for. The procedure is again described in AN2012_126, located here on CADi.

## January 10, 2013

Discussed the addition of the relevant information for the C-tagging (via D-meson reconstruction) and B-tagging into the official HiForest release. The word was that it's probably best to do the first round of HiForest production as is and complete the proposed fast analyses, and then once the first round is finished, then work on adding the relevant information into the revised HiForest. The main suggestion was that we should look into creating a D-meson tree (perhaps with branches for D and D*, etc).

#### Revision 262013-01-16 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## January 10, 2013

Line: 18 to 18

• PYSTAT in log files should contain the tried number of events for each successful embedding event. If that doesn't work, it might be useful to simply count the number of times that PYTHIA was initialized, since it's printed every time in the logfile. Using either of these methods, it should be more or less trivial to obtain the total number of events tried before embedding. This allows us to find the equivalent number of min-bias events used to obtain the luminosity corrections for each pt-hat bin.
• Need 50K events in pt-hat bins of:
• 10+ (completed 12/19)
Changed:
<
<
• 20+ (completed 1/3... recoing...)
• 30+
• 50+
>
>
• 20+ (completed 1/3)
• 30+ (completed 1/15... recoing)
• 50+ (postponed until after pPb run ((March?)) )

• Official Production of the sample has also been requested: here
• Basic reconstruction should work for these samples
• Subevents are probably not treated properly in the Hijing version from 12/17, but it might be good enough for a first pass

#### Revision 252013-01-10 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## January 10, 2013

Discussed the addition of the relevant information for the C-tagging (via D-meson reconstruction) and B-tagging into the official HiForest release. The word was that it's probably best to do the first round of HiForest production as is and complete the proposed fast analyses, and then once the first round is finished, then work on adding the relevant information into the revised HiForest. The main suggestion was that we should look into creating a D-meson tree (perhaps with branches for D and D*, etc).

The presentation that was given in the high-pt group is here

## December 19, 2012

Changed:
<
<
Detailed and complete (mostly) outline for b-jet cross-section study
>
>
Detailed and complete (mostly) outline for b-jet cross-section study (Further elaboration at the attached pdf)

>
>

• Creation of the B-Jet and inclusive Jet MC Samples
• use the fixed 50K Hijing sample I created for testing to avoid any possible weird errors that may pop up in AMPT. Hijing at this point is much more trustworthy and reliable. In addition, Hijing is able to do more than 20 events at a time.
• Use pythia dijet embedding in a Hijing background - script in CMSSW_5_3_3_patch3
Line: 13 to 21

• 20+ (completed 1/3... recoing...)
• 30+
• 50+
>
>
• Official Production of the sample has also been requested: here

• Basic reconstruction should work for these samples
• Subevents are probably not treated properly in the Hijing version from 12/17, but it might be good enough for a first pass
• Finally, create the HiForest sample using the modified B-Jet HiForest ready in CMSSW_5_3_3_patch3
Line: 646 to 655

 META FILEATTACHMENT attachment="L1JetTrgConfig.gif" attr="" comment="L1 Jet Trigger Configuration" date="1336937287" name="L1JetTrgConfig.gif" path="L1JetTrgConfig.gif" size="59888" stream="L1JetTrgConfig.gif" tmpFilename="/usr/tmp/CGItemp11067" user="kjung" version="1" attachment="antiKtPerf.gif" attr="" comment="Anti-kT algorithm performance" date="1337097998" name="antiKtPerf.gif" path="antiKtPerf.gif" size="106307" user="kjung" version="1" attachment="b_tagging_graphic.png" attr="" comment="shows how b-tagging wrt impact parameters work" date="1337190651" name="b_tagging_graphic.png" path="b_tagging_graphic.png" size="82803" user="kjung" version="1"
>
>
 META FILEATTACHMENT attachment="BTagJEC-kjung.pdf" attr="" comment="" date="1357850743" name="BTagJEC-kjung.pdf" path="BTagJEC-kjung.pdf" size="207463" user="kjung" version="1" attachment="bJetProdRequest.pdf" attr="" comment="" date="1357850992" name="bJetProdRequest.pdf" path="bJetProdRequest.pdf" size="32913" user="kjung" version="1" attachment="BJet-HiForestAdditions-kjung.pdf" attr="" comment="" date="1357851276" name="BJet-HiForestAdditions-kjung.pdf" path="BJet-HiForestAdditions-kjung.pdf" size="161702" user="kjung" version="1"

#### Revision 242013-01-09 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## December 19, 2012

Line: 10 to 10

• PYSTAT in log files should contain the tried number of events for each successful embedding event. If that doesn't work, it might be useful to simply count the number of times that PYTHIA was initialized, since it's printed every time in the logfile. Using either of these methods, it should be more or less trivial to obtain the total number of events tried before embedding. This allows us to find the equivalent number of min-bias events used to obtain the luminosity corrections for each pt-hat bin.
• Need 50K events in pt-hat bins of:
• 10+ (completed 12/19)
Changed:
<
<
• 20+
>
>
• 20+ (completed 1/3... recoing...)

• 30+
• 50+
• Basic reconstruction should work for these samples

#### Revision 232012-12-21 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## December 19, 2012

Detailed and complete (mostly) outline for b-jet cross-section study

>
>

• Creation of the B-Jet and inclusive Jet MC Samples
• use the fixed 50K Hijing sample I created for testing to avoid any possible weird errors that may pop up in AMPT. Hijing at this point is much more trustworthy and reliable. In addition, Hijing is able to do more than 20 events at a time.
• Use pythia dijet embedding in a Hijing background - script in CMSSW_5_3_3_patch3
Line: 14 to 15

• 50+
• Basic reconstruction should work for these samples
• Subevents are probably not treated properly in the Hijing version from 12/17, but it might be good enough for a first pass
Changed:
<
<
• Finally, create the HiForest sample using the modified B-Jet HiForest ready in CMSSW_5_3_3_patch3
• Ensure the GenJet collections are kept!!
>
>
• Finally, create the HiForest sample using the modified B-Jet HiForest ready in CMSSW_5_3_3_patch3
• Ensure the GenJet collections are kept!!

• Calculation of purity
Changed:
<
<
• Extract purity from the MC samples and fit it to the function described in CMS AN-2011/279
• Purity = N(bjets) / N(total jets) in a b-tagged sample = FbEb / FbEb + FcEc + FlEl, where Fx = relative fraction of x jets, and Ex = tagging efficiency of x jets.
>
>
• Extract purity from the MC samples
• Purity = N(bjets) / N(total jets) in a b-tagged sample (using the SSVHPT, simple secondary vertex, high purity algorithm) = FbEb / FbEb + FcEc + FlEl, where Fx = relative fraction of x jets, and Ex = tagging efficiency of x jets.

• Then we plot the secondary vertex mass distribution for the MC samples and use the shapes of the B-jets, C-jets and light jets as templates. For this particular study, we will plan on creating only a b-jet and a light jet template.
• Then we use these templates and apply them to the shape of the secondary vertex mass distribution in data.
>
>
• The light flavor contribution is expected to be almost negligible after this tagger is applied

• These templates are applied to a btagged and an anti-btagged sample for the efficiency study.
• Using the templates, we can then calculate purity in Data and MC and fit it to a functional form:
>
>
• After fitting the MC and Data to this function, we can then define the Scale Factor as the ratio of the Data purity fit / MC purity fit. This is to be done within 5 distinct rapidity bins and plotted as a function of .
• Calculation of efficiency
• Once purity is calculated, finding efficiency is fairly straightforward.
• Essentially, we have a b-tagged and a anti-btagged sample based on the b-tagging algorithm of our choosing (at first, we will use SSVHPT, unless statistics are very poor, then we will try SSVHE, or even JP).
• Once we have the b-jet fraction in each sample (analogous to purity, derived in the previous step), it is a simple matter to calculate the efficiency:
• and .
• This is the calculation of the number of bjets I actually have total from both samples (in my entire sample).
• Then, . This is easily calculated for both data and MC.
• Once we have the b-jet efficiency for data and MC, it's a similar procedure as the purity to calculate the Data/MC Scale Factor, instead the functional form is slightly different:
• Corrections
• Unfolding / Smearing Corrections () - Bin-by-bin Method. Yen-Jie has discussed that this may not be the best way for publication, but for a first look, it's fine.
• The idea is to smear the true spectrum using the known resolutions and fit to the data using an ansatz function.
• First we have to assume a gaussian width of the smearing, and convolute it with the ansatz function.
• We should do this in the same 5 eta bins as everything else, and again, as a function of .
• I don't think the ansatz function itself matters too much... it should be cancelled out by the division of the data/MC, but I need to ask about this!.
• The procedure is to find , where f is the ansatz function and g is the smearing gaussian. I believe the smearing gaussian can simply be looked up or asked for, but again it's something to be asked about.
• For completeness sake, the ansatz function they recommend in AN-2011/279 is:
• , where = 5, motivated by the parton model described by Bjorken, Feynman, et. al. in 1971 and 1978.
• Finally, once we find the in data and MC, the smearing factor is simply f(data) / f(MC) as a function of .
• Basic Jet Energy Corrections
• These corrections can be broken down into four parts and need to be well understood:
• Offset Correction:
• Corrects for background noise and pileup. Corrected via the Jet Area method:
• Need to calculate the average pT density per unit area in bins of number of primary vertices. We then assume events that have exactly 1 primary vertex are not pile-up events and use this as the underlying event measurement.
• Then,
• This is calculated as a function of the leading jet pT.
• MC Calibration
• Corrects the average reco jet pT to the average pT of the Gen Jets. Measured as a function of the reconstructed pT and done, again in the 5 eta bins.
• Relative Eta Correction
• Corrects for the fact that the jet energy response depends on because the detector coverage depends on .
• Somewhat complicated correction using the asymmetry in positive and negative along with comparing the response in data and MC. Unfortunately this correction can affect the jet energy up to ~10% in pp, so it's probably worth the effort.
• Start by creating an analysis sample enriched with dijets balanced in the transverse plane by applying a cut on the third jet (should one exist). Normally, this cut is applied on the ratio , where usually equals 0.2.
• Measure this response in data and MC and find the ratio of the two: .
• Then, since the final state radiation and underlying event mechanics are not perfectly modeled in MC, we apply a correction where we extrapolate alpha to 0:
• Finally, we define the asymmetry with respect to eta in a final equation:
• , similar to the dijet quantity .
• Then, putting it all together gives us a really messy (but unfortunately necessary) equation:
• Jet Resolution Effects
• These correct any mean pT shift due to the resolution effects. It's slightly different than C(smear) because C(smear) corrects the width, and not the mean of the average jet energy response gaussian.
• Essentially, the point is to use the photon or Z boson for calibration because the response of these two observables are much tighter than in jets. Unfortunately, it's not clear yet whether these methods are going to be worthwhile in pPb collisions, due to possible dijet suppression. These studies rely on the fact that the total jet energy is roughly symmetric in all directions, and if jet suppression exists, this assumption is no longer true. If it is discovered that suppression is small in the Dijet paper released shortly after the pPb run, these effects will be studied. Else, for now, they can be absorbed into systematic errors.

ISSUES YET TO BE SOLVED!

• Subevent tracking in Hijing / AMPT is not yet implemented... This might lead to issues with the jet smearing, like Pelin and Yaxian are having now with the Jet Shapes paper (HIN-12-002).
• pt-hat bins for private study is different than those requested for official production (30+, 50+, 80+, 120+, 170+). This is probably okay, since we just want to get a feel for the procedure now, and specifically try out calculation of b-jet cross-section in the low pT range in order to overlap with possible RHIC studies (also produced by Purdue?).
• Jet Resolution - Is suppression small enough in pPb such that dijet balancing is possible?

## December 14, 2012

#### Revision 222012-12-20 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## December 19, 2012

Line: 13 to 13

• 30+
• 50+
• Basic reconstruction should work for these samples
>
>
• Subevents are probably not treated properly in the Hijing version from 12/17, but it might be good enough for a first pass

• Finally, create the HiForest sample using the modified B-Jet HiForest ready in CMSSW_5_3_3_patch3
• Ensure the GenJet collections are kept!!
• Calculation of purity
Line: 20 to 21

• Purity = N(bjets) / N(total jets) in a b-tagged sample = FbEb / FbEb + FcEc + FlEl, where Fx = relative fraction of x jets, and Ex = tagging efficiency of x jets.
• Then we plot the secondary vertex mass distribution for the MC samples and use the shapes of the B-jets, C-jets and light jets as templates. For this particular study, we will plan on creating only a b-jet and a light jet template.
• Then we use these templates and apply them to the shape of the secondary vertex mass distribution in data.
>
>
• These templates are applied to a btagged and an anti-btagged sample for the efficiency study.
• Using the templates, we can then calculate purity in Data and MC and fit it to a functional form:

## December 14, 2012

#### Revision 212012-12-20 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## December 19, 2012

#### Revision 202012-12-19 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## December 19, 2012

Detailed and complete (mostly) outline for b-jet cross-section study

• Creation of the B-Jet and inclusive Jet MC Samples
• use the fixed 50K Hijing sample I created for testing to avoid any possible weird errors that may pop up in AMPT. Hijing at this point is much more trustworthy and reliable. In addition, Hijing is able to do more than 20 events at a time.
• Use pythia dijet embedding in a Hijing background - script in CMSSW_5_3_3_patch3
• PYSTAT in log files should contain the tried number of events for each successful embedding event. If that doesn't work, it might be useful to simply count the number of times that PYTHIA was initialized, since it's printed every time in the logfile. Using either of these methods, it should be more or less trivial to obtain the total number of events tried before embedding. This allows us to find the equivalent number of min-bias events used to obtain the luminosity corrections for each pt-hat bin.
• Need 50K events in pt-hat bins of:
• 10+ (completed 12/19)
• 20+
• 30+
• 50+
• Basic reconstruction should work for these samples
• Finally, create the HiForest sample using the modified B-Jet HiForest ready in CMSSW_5_3_3_patch3
• Ensure the GenJet collections are kept!!
• Calculation of purity
• Extract purity from the MC samples and fit it to the function described in CMS AN-2011/279
• Purity = N(bjets) / N(total jets) in a b-tagged sample = FbEb / FbEb + FcEc + FlEl, where Fx = relative fraction of x jets, and Ex = tagging efficiency of x jets.
• Then we plot the secondary vertex mass distribution for the MC samples and use the shapes of the B-jets, C-jets and light jets as templates. For this particular study, we will plan on creating only a b-jet and a light jet template.
• Then we use these templates and apply them to the shape of the secondary vertex mass distribution in data.

## December 14, 2012

Uncovered the true source of the CONDOR issues at MIT. The problem is that the pythonpath variable fails to pick up the new python 2.6 dependencies when sending to a remote node. The fix, then, is to add this right before you call cmsRun in your remote script:


export PYTHONPATH=$PYTHONPATH:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python26.zip:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6/plat-linux2:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6/lib-tk:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6/lib-old:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6/lib-dynload:/osg/app/cmssoft/cms/slc5_amd64_gcc462/external/python/2.6.4/lib/python2.6/site-packages  If that fails, you might need additional dependencies that I don't have. What you can do is run your cfg via python -i cfg.py. Then call: import sys sys.path  And check for differences between what gets printed and what's stored in$PYTHONPATH. Whatever is missing should be appended to PYTHONPATH before running on a remote node.

## November 29, 2012

Condor Fixes due to MIT updating on 11/19 -

#### Revision 192012-11-30 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## November 29, 2012

Condor Fixes due to MIT updating on 11/19 -

So it seems that I can no longer run some of the required python imports via CONDOR. Everything imports correctly when running interactively, but all the CONDOR jobs fail to import either python.os or python.cStringIO. The fixes I implemented were:

• Removed any dependencies on ivars - this includes condor input and output filenames and the random number seeds

## October 2, 2012

Hijing Generation of Heavy quarks (no embedding) -

(all these flags are on line 5833)

IHPR2(3) = 3 //Sets Hijing to Heavy quark production (instead of min bias). This induces charm production by default. IHPR2(18) = 0 //for charm, =1 for bottom production

HIPR1(10) = 0 //turns on inclusive sample jet production HIPR1(7) = heavy quark mass used in calculation. = 1.5 for charm (default), = 4.2 for bottom.

## September 28, 2012

Hijing Notes -

- Hijing needs to be debugged in CMSSW. The biggest problem we've run into with Hijing is that we can get memory overflow errors and array overflow errors with very high multiplicity events. I'm very surprised this wasn't an issue when they were doing the Pb-Pb analysis. I think they used Pyquen exclusively, so the Hijing and AMPT errors weren't an issue then. Nevertheless, the Hijing implementation in CMSSW is not well understood. The bug fixes that Yue-shi implemented are here. They mainly relate to some array overflow errors and handling events with thousands of tracks (which is rare, but happens even in p-Pb).

- Additional note = Flag IHPR(21) = 1 (line 5833) turns on the retaining of all decayed particle information. This means that decayed B's and D's, for example, will be passed to Geant. It's not clear yet whether Geant interprets these as real particles and decays them again, but it doesn't seem likely. I think Hijing particles have a "decayed" flag, which Geant picks up on. Without this flag, you don't see any B and D particles in a standalone hijing. They do show up in geant, but the question is: is this the behavior that we want? I think yes - the CMS rule is to decay all particles with a lifetime shorter than the distance to any detector component within the generator itself, i.e. not rely on Geant to do any decays of very short-lived particles.

## September 24, 2012

So I've been here for two weeks now - just need to make a quick addendum:

#### Revision 152012-09-25 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## September 24, 2012

So I've been here for two weeks now - just need to make a quick addendum:

Places to Stay - If you're going to stay less than 2 weeks, definitely just stay in the CERN hostels. You'll spend a little more because you'll be eating either at the CERN restaurant or out, but the rooms are nice enough and the internet is fast-ish and it's really convenient to be on site.

- If you're staying for longer than 2 weeks, but less than 3 or 4 months, I really recommend the Aparthotel in St. Genis - Pouilly, France. Make sure you ask about the CERN rates. If there's two people (or 3 if you don't mind sharing a room), this is a better deal than the hostel. It's slightly cheaper on rent (though not by much), but you save a lot of money on food. You'll get a fridge and a stove top, and there's a Carrefour right down the street that has enough food to get you through a couple of months. Their link is here.

- If you're staying for longer than a few months (ideally 6 months+), look into renting a real apartment. The CERN Users' Office site has a bunch of good information on this front. I would check that out.

## September 13, 2012

Arrived at CERN and started to settle in. Getting here was a hassle, so I want to put a reference here regarding the things that need to take place before you get here as a US citizen:

#### Revision 142012-09-13 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## September 13, 2012

Arrived at CERN and started to settle in. Getting here was a hassle, so I want to put a reference here regarding the things that need to take place before you get here as a US citizen:

Check your passport - Make sure your passport has at least 6 months of validity left from the departure date.

Request a "Convention d'Accueil" - For this you'll need to contact Yasmin Yazgan at yasemin.uzunefe.yazgan@SPAMNOTcernNOSPAMPLEASE.ch. Obviously remove the spamnot part. Just tell her how long you're staying at CERN and she'll request that you provide her with a bunch of other information like name and birthdate, etc and then will draft and send you the Convention. Print it, sign it, and bring it with you.

Request a letter of employment from your university - Make sure you bring a letter signed by the department that gives your START AND END dates of employment. Just so long as the end date is after you're planning on leaving CERN, you should be fine. Print it and bring it with you.

Fill out this form - Make sure your group head signs it before you go. It's seriously a hassle if you have to fax stuff around because of the the +6 hour time change. Print it and fill it out, have it signed, and bring it with you.

Make sure your Visa situation is in order - If you're staying for longer than 90 consecutive days, you'll need to apply for a visa. I don't think this is a big deal (I didn't have to do it since I'm only staying for 60 days), but I think there is documentation online for this here.

Book your flight - Geneva has very few direct flights from the United States, so unless you live on the east coast, expect to transfer planes at least once. We went from Chicago -> Washington DC -> Geneva through United.

Find a place to live - As far as I can tell, it's extremely difficult to find a place to live unless you know someone currently at CERN willing to help you out. I believe most of the time, visits to the apartment is mandatory as most hosts want to meet their clients before signing a lease. I decided to stay a week at the CERN hostel (BOOK EARLY!) and am currently trying to find a place while here, within that first week. Expect to spend at least 1000 CHF / month for a sublease. Anything under this is either a pretty good deal, or you're about to get ripped off. Also note that many landlords require a 3 month stay for apartments, so if you're going to be at CERN for less than that amount of time, make sure you say that before you make arrangements to travel all the way out to an apartment

Request a travel advance - Purdue offers travel advances, so if you're a broke graduate student (like me!), you'll need to pick up some spending cash before you go so you can afford to pay for an apartment or lodging or food, etc. I know Purdue requires 5 business days to process one of these, so make sure you do this at least a week or two ahead of time.

Make sure your credit card companies know you'll be abroad - Most credit card companies assume a withdrawal from Europe on a US credit card means that you're card's been stolen. To avoid this, just call them and tell them you'll be in Switzerland and/or France. They'll take care of it by putting a travel notice on your card.

## August 28, 2012

So Quark Matter 2012 really interrupted my CMS work. I'm planning on now moving all production to MIT since Purdue's systems give me the most annoying errors. I guess most jobs can't seem to stage-out the files that I need, so they simply crash and burn. It seems to happen on most nodes, and though they all usually fail, sometimes a few will make it through. I think there must be some kind of memory or hard drive space constraint when using the grid through Purdue, but the local submission through condor is not worth my time to figure out. It makes more sense to move all production to MIT instead.

#### Revision 132012-08-28 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## August 28, 2012

So Quark Matter 2012 really interrupted my CMS work. I'm planning on now moving all production to MIT since Purdue's systems give me the most annoying errors. I guess most jobs can't seem to stage-out the files that I need, so they simply crash and burn. It seems to happen on most nodes, and though they all usually fail, sometimes a few will make it through. I think there must be some kind of memory or hard drive space constraint when using the grid through Purdue, but the local submission through condor is not worth my time to figure out. It makes more sense to move all production to MIT instead.

It seems a lot has changed since this last update. For starters, we've migrated to CMSSW_5_3_3 for the AMPT production, since this will be the CMSSW version used for the Pilot Run in Sept. This was quite a bitch to get working, since they've migrated to using symbolic global tags and, therefore, it makes much more sense to use the cmsDriver.py function for each successive update of CMSSW and global tag. Some of the required data needs to be pulled in via the frontier://FrontierProd/... sourcing. In the end, you'll need to do something like this:

 cmsDriver.py Hydjet_Quenched_MinBias_2760GeV_cfi -s GEN,SIM,DIGI,L1,DIGI2RAW,HLT:GRun -n 10 --conditions auto:startup_GRun --datatier GEN-SIM-RECODEBUG --eventcontent FEVTDEBUGHLT --scenario HeavyIons --no_exec

The auto:startup_GRun automatically pulls in the appropriate global tag that corresponds to the CMSSW version that you've established via the cmsenv command (which I'm sure sets a bunch of environment variables).

I'm travelling to CERN from Sept. 10 - Nov. 9, so hopefully I'll be able to at least see the pilot run and start work on my jet tagging code using the pilot run data. In addition, I'd really like to be trained to be an HLT on call person for the real p-Pb run in January / February.

Once my MIT account is assigned, my plan is to then work on hiForesting the data that Lingshan currently has produced on the MIT disk. Then I can start to make plots using the generated data with trigger decisions and come up with some various analyses to aid in development of the trigger menu for the production run in January.

## June 27, 2012

Update on the production of AMPT-generated events. We need to have:

#### Revision 122012-06-27 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## June 27, 2012

Update on the production of AMPT-generated events. We need to have:

• 5.02 TeV center of mass energy
• Include the ZDC information
• To do this, you need to use the GeometryDB_cff file
• Along with the updated global tag. For Heavy Ion, it should be STARTHI50_V16::All
• Include the Castor Information (HF forward tracker, not the storage space)
• Need to add the following lines:
process.g4SimHits.Generator.MinEtaCut = -7.0
process.g4SimHits.Generator.MaxEtaCut = 5.5
process.g4SimHits.CastorSD.nonCompensationFactor = cms.double(0.77) 
• Want to make the Pb the projectile and p the target (that way the particle spray is in the forward eta direction).
• Need to include the rapidity shift code (written by Lingshan), check-outable from cvs via cvs co UserCode/lixu/PPbBoost/
• Need the process to run on CMSSW_5_1_3 (5_0_1 won't submit jobs properly since it's not in the grid database)

I've included all these things in a py script, located on Purdue at ~/CMSSW_5_1_3/src/GeneratorInterface/AMPTInterface/test/pPb_vtxBoost.py

When the Simulation is complete, the raw and reco data will be posted on the PPb Simulation twiki for 2012.

The next step I need to accomplish (one this generation step is completed and verified) is to do reconstruction and then run the hiForest on the reconstructed data. This should allow be to get the L1 trigger decisions from which I can get a good feel for the trigger rates, etc. It has already been verified that the OpenHLT produces the same information as the hiForest production, and since many more people are working on the hiForest as opposed to the HLT, I feel like it's a better decision to move to hiForest.

More updates coming soon. I'd like to have ~5K events produced by the end of the week to verify.

## May 24, 2012

More hints - I figured out a way to dump all the input tags from a EDAnalyzer to a file, in order for easy searching if you have lots of input tags (Like in the case of the OpenHLT framework). To do this, you need to:

#### Revision 112012-05-24 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 24, 2012

More hints - I figured out a way to dump all the input tags from a EDAnalyzer to a file, in order for easy searching if you have lots of input tags (Like in the case of the OpenHLT framework). To do this, you need to:

python -i configuration file | tee output.txt , then run whatever command line you need. In my case, just process.hltanalysis.

This will redirect all the output to the screen to a file, from which you can search for what you need.

In addition, if you want to dump Root TTree Content to a file, Phillipe's explanation on this page works pretty well.

## May 22, 2012

Couple of hints and tips from yesterday and this morning: Using srmls and srmcp at Purdue requires a very specific voms proxy. It requires you to ensure you call the cms voms server via voms-proxy-init -voms cms . Also be sure to encapsulate any wild cards or logins in single quotes (especially if you're using a csh environment, as I am). I am considering switching to the .sh environment, because it seems like most scripts are written with this shell in mind. Translation is a simple matter though - most of the time you just need to change any export commands to a setenv and you'll be all set. A simple find and replace in vi usually takes care of this. Maybe I'll write a shell translation script. Might be useful.

#### Revision 102012-05-22 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 22, 2012

Couple of hints and tips from yesterday and this morning: Using srmls and srmcp at Purdue requires a very specific voms proxy. It requires you to ensure you call the cms voms server via voms-proxy-init -voms cms . Also be sure to encapsulate any wild cards or logins in single quotes (especially if you're using a csh environment, as I am). I am considering switching to the .sh environment, because it seems like most scripts are written with this shell in mind. Translation is a simple matter though - most of the time you just need to change any export commands to a setenv and you'll be all set. A simple find and replace in vi usually takes care of this. Maybe I'll write a shell translation script. Might be useful.

As for the trigger primitive matching, It's been significantly more challenging than I expected. For some reason, I can't get the code that Matt Nguyen provided, here, to work. There's a mismatch between the reconstructed vertex input tag that I have in the AMPT-generated files and the input tag the code is looking for. I changed the names to match just fine, but the code is looking for an object of type std::vector<reco::Vertex>, but the ntuple has type edm::Wrapper< vector<reco::Vertex> >. Maybe I can remove the wrapper somehow? I guess that's today's project. I emailed Matt and Frank asking for a solution, but no response yet.

Finally, I have to make sure to be very careful not to exceed quota at the purdue home directory. Returned files from crab jobs very quickly fill up a directory and I have to remember to crab -clean or at least delete the root files after I've retrieved them. I only have 4.6 GB, which goes fast.

## May 17, 2012

I need to look into this trigger reconstruction further. The presentation I had last week was a simple ratio of events that fired the trigger to total events, which is nice if you're looking at pure trigger rates, but if you want a more robust analysis of what's actually firing the triggers, you need to be able to match the reconstructed jets to their L1 triggered primitives, i.e. did this jet actually fire this trigger, or was it a random other physics process?
Line: 32 to 40
Jet Probability Algorithm Inputs: Impact Parameter Significance
Changed:
<
<
This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R. The negative tracks are used here because they are mainly primary tracks (almost assuredly not b-jet tracks). This resolution function, then, is used as a distribution of impact parameter significance, binned in a fine enough grain such that we avoid any artificial binning effects. Under Construction
>
>
This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R. The negative tracks are used here because they are mainly primary tracks (almost assuredly not b-jet tracks). This resolution function, then, is used as a distribution of impact parameter significance, binned in a fine enough grain such that we avoid any artificial binning effects. Once the resolution function is determined, we then say that the signed probability of a track to have come from the primary vertex is expressed as . Since jets have more than one track, however, we must also express the probability that a jet (as a collection of tracks) comes from the primary vertex. We express the probability that any of a collection of N tracks did not come from a long lived particle (or, equivalently, the probability that all of the N tracks came from the primary vertex) as , where . is used to weight for negative track impact parameters, as it is more likely that the track is a primary track if the impact parameter is negative. Therefore, we define it as for positive, and for negative. Finally, using this ordered probability, we pick out the jet candidates that are most likely from b-jets.

Other Algorithms Inputs: Vary

There also exist some leptonic algorithms for b-tagging jets that exploit the fact that the branching ratio for b into electrons and muons is ~19% for each family. These algorithms are more rare, and are usually used in conjunction with the impact parameter significance algorithms described above, so I won't go into too much detail. Basically, the idea is you find the leptons among the tracks that are associated with a jet. This requires a very pure sample of electrons and muons, though various track cuts exist to obtain pure samples of both these particles. The majority of the work and CPU power associated with this method is non-lepton rejection and elimination of sample contamination.

One can also reconstruct the secondary vertex and apply various selection cuts on the primary vertex to exclude decays, etc. This is the combined secondary vertex tag and is usually used in conjunction with other algorithms.

Finally, we can do some b-tagging at the HLT Level. Generally, this technique uses only the pixel hits to do reconstruction, which provides a significant decrease in sensitivity, but enough of a boost in speed to allow for the online tagging to occur at all. Nevertheless, it turns out that this technique is sufficiently reliable that meaningful online b-tagging can be done. Using this shortcut, along with taking only the top 2 jets in , gives us enough of a performance enhancement that we can do the track counting algorithm (described above) at the HLT level.

## May 14, 2012

The HLT and Reco Jet reconstruction algorithms are not incredibly complicated, which is nice. I aim to give a summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes both the HLT and Reco steps.
Line: 260 to 276
Using FWLite requires the use of fwlite::Handles, which act as branches in TTrees -> Handle.getbyLabel(). edm::EventBase works the same way but integrates into cmsRun.
Changed:
<
<

>
>

## References

[1]: B-tagging of Jets Example: http://www-d0.fnal.gov/Run2Physics/top/singletop_observation/

#### Revision 92012-05-21 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## May 17, 2012

Line: 32 to 32
Jet Probability Algorithm Inputs: Impact Parameter Significance
Changed:
<
<
This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R, which (STILL UNDER CONSTRUCTION)
>
>
This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R. The negative tracks are used here because they are mainly primary tracks (almost assuredly not b-jet tracks). This resolution function, then, is used as a distribution of impact parameter significance, binned in a fine enough grain such that we avoid any artificial binning effects. Under Construction

## May 14, 2012

The HLT and Reco Jet reconstruction algorithms are not incredibly complicated, which is nice. I aim to give a summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes both the HLT and Reco steps.

#### Revision 82012-05-17 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 17, 2012

I need to look into this trigger reconstruction further. The presentation I had last week was a simple ratio of events that fired the trigger to total events, which is nice if you're looking at pure trigger rates, but if you want a more robust analysis of what's actually firing the triggers, you need to be able to match the reconstructed jets to their L1 triggered primitives, i.e. did this jet actually fire this trigger, or was it a random other physics process?

My thoughts were to include the MC data into the OpenHLT framework, but this is proving more difficult than I originally thought. It looks like the OpenHLT doesn't do any native reconstruction, so I might need to add that in manually if I'd like to ensure the MC data gets filled into the OpenHLT ntuple. Everything I've seen online here makes it look like OpenHLT should be able to run on RAW data. Further study is needed. I emailed Frank Ma and Matt Nguyen to confirm. Hopefully this can be resolved by the end of the week.

## May 16, 2012

Looked at tagging and b-tagging of jets for the past couple of days. I'll start with b-tagging.
Line: 27 to 32
Jet Probability Algorithm Inputs: Impact Parameter Significance
Changed:
<
<
This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R, which
>
>
This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R, which (STILL UNDER CONSTRUCTION)

## May 14, 2012

The HLT and Reco Jet reconstruction algorithms are not incredibly complicated, which is nice. I aim to give a summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes both the HLT and Reco steps.

#### Revision 72012-05-16 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## May 16, 2012

Line: 19 to 19
caption="B-Tagged Jet Example [1]" }%
Changed:
<
<
These types of algorithms rely heavily on the efficient track reconstruction mentioned above. In essence, this algorithm sorts all tracks from an event in terms of a three-dimensional "impact parameter," which characterizes how positively displaced (along the jet direction, from the primary vertex) the particle track is. For example, if a track is very heavily characteristic of a b-particle, we would find that there would be a few tracks that have a vertex displaced a bit from the primary vertex, but most importantly, these tracks would be displaced in the same direction as the jet. See picture to the right. This secondary vertex is the point of decay of the b-particle
>
>
These types of algorithms rely heavily on the efficient track reconstruction mentioned above. In essence, this algorithm sorts all tracks from an event in terms of a three-dimensional "impact parameter," which characterizes how positively displaced (along the jet direction, from the primary vertex) the particle track is. For example, if a track is very heavily characteristic of a b-particle, we would find that there would be a few tracks that have a vertex displaced a bit from the primary vertex, but most importantly, these tracks would be displaced in the same direction as the jet. See picture to the right. This secondary vertex is the point of decay of the b-particle, so the more "along the jet" the secondary vertex is, the more characteristic the jet is of a b-jet. In addition, we also usually sign the displacement. Often times, negatively displaced tracks arise from the displacement calculation. These negatively displaced tracks are characteristic of many things, but primarily the finite detector resolution, which can output a poor measurement of the track parameters or even the primary vertex. In addition, beam pipe and pixel layer scattering can also affect these measurements. These negative parameters are useful, however, as one usually uses these to obtain the b-tagging efficiency for jets that have no b-particle or c-particle correlation.

Track Counting Algorithm (HLT-capable). Inputs: Impact Parameter Significance, N tracks per jet

Very simple algorithm, thought it requires fast online jet reconstruction (usually iterative cone). First, the highest N tracks in a jet are ordered based on impact parameter significance. Then, depending on N, usually either 2 (for higher speed), or 3 (for higher purity) highest impact parameter tracks are calculated. If the Nth track passes the designated impact parameter significance threshold, the jet is tagged as a b-jet.

Jet Probability Algorithm Inputs: Impact Parameter Significance

This algorithm is significantly more complicated, though it runs with the same basic idea as the track counting algorithm. In this case, though, instead of simply having a particle pass a threshold, we require the total jet to pass some certain probability threshold. First, we use the tracks with a negative impact parameter to extract a resolution function R, which

## May 14, 2012

The HLT and Reco Jet reconstruction algorithms are not incredibly complicated, which is nice. I aim to give a summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes both the HLT and Reco steps.

#### Revision 62012-05-16 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 16, 2012

Looked at tagging and b-tagging of jets for the past couple of days. I'll start with b-tagging.

B-tagging of jets is useful because it allows us direct access to a few very interesting physics channels, including top quarks, Higgs bosons, and Supersymmetric (SUSY) particles. All these primarily decay into bottom quarks (top quarks through CKM matrix, Higgs because decays depend on f mass, and SUSY particles ??). There are 5 basic algorithms used to do b-tagging of jets. Most of these tagging algorithms use the distinctive lifetime properties of the b-hadrons (). These tagging schemes are usually applied offline, but some that are quick enough can be applied at the HLT Level. I will do my best to denote each algorithm that can be applied at HLT (usually level 2.5 or 3).

Physics Object Reconstruction

Many of the b-tagging algorithms require properly tagged lower-level physics objects. Since most b's create jets, jet tagging is crucial, especially since we're looking for b's within jets to begin with. Most b-tagging algorithms requiring jets use the iterative cone algorithm with a cone size R = 0.5. In addition, we require extremely precise track reconstruction, especially close to the interaction point. Indeed, the track measurement precision in terms of the impact parameter is probably the most crucial measurement required to effectively tag b-particles. These measurements allow us to directly measure the long lifetime of the b-particle.

Track Impact Parameter-based Tags

B-Tagged Jet Example [1]

These types of algorithms rely heavily on the efficient track reconstruction mentioned above. In essence, this algorithm sorts all tracks from an event in terms of a three-dimensional "impact parameter," which characterizes how positively displaced (along the jet direction, from the primary vertex) the particle track is. For example, if a track is very heavily characteristic of a b-particle, we would find that there would be a few tracks that have a vertex displaced a bit from the primary vertex, but most importantly, these tracks would be displaced in the same direction as the jet. See picture to the right. This secondary vertex is the point of decay of the b-particle

## May 14, 2012

The HLT and Reco Jet reconstruction algorithms are not incredibly complicated, which is nice. I aim to give a summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes both the HLT and Reco steps.
Line: 227 to 247
Using FWLite requires the use of fwlite::Handles, which act as branches in TTrees -> Handle.getbyLabel(). edm::EventBase works the same way but integrates into cmsRun.
>
>

## References:

[1]: B-tagging of Jets Example: http://www-d0.fnal.gov/Run2Physics/top/singletop_observation/

-- KurtJung - 11-May-2012

Line: 235 to 259

 META FILEATTACHMENT attachment="JetTrgAlgo.gif" attr="" comment="Calorimeter Jet Trigger Algorithm" date="1336936981" name="JetTrgAlgo.gif" path="JetTrgAlgo.gif" size="34521" stream="JetTrgAlgo.gif" tmpFilename="/usr/tmp/CGItemp11209" user="kjung" version="1" attachment="L1JetTrgConfig.gif" attr="" comment="L1 Jet Trigger Configuration" date="1336937287" name="L1JetTrgConfig.gif" path="L1JetTrgConfig.gif" size="59888" stream="L1JetTrgConfig.gif" tmpFilename="/usr/tmp/CGItemp11067" user="kjung" version="1" attachment="antiKtPerf.gif" attr="" comment="Anti-kT algorithm performance" date="1337097998" name="antiKtPerf.gif" path="antiKtPerf.gif" size="106307" user="kjung" version="1"
>
>
 META FILEATTACHMENT attachment="b_tagging_graphic.png" attr="" comment="shows how b-tagging wrt impact parameters work" date="1337190651" name="b_tagging_graphic.png" path="b_tagging_graphic.png" size="82803" user="kjung" version="1"

#### Revision 52012-05-15 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"

## May 14, 2012

Changed:
<
<
The HLT and Reco algorithms are not incredibly complicated, which is nice. I aim to give a nice summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes the HLT and Reco steps.
>
>
The HLT and Reco Jet reconstruction algorithms are not incredibly complicated, which is nice. I aim to give a summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes both the HLT and Reco steps.

Changed:
<
<
HLT Jet Finding Algorithm - "Iterative Cone Method."
>
>
HLT Jet Finding Overview

Changed:
<
<
Even with this fast iterative cone method, the algorithm cannot keep up with the L1 readout unless there's a very high jet energy threshold (1 Hz = 650 GeV (one jet)). Usually you need something else besides the pure jet to have an acceptable rate with an acceptable threshold. Also note that each calorimeter tower corresponds to 1 HCal, and one 5x5 section of PbWO4 ECal pads. Noise elimination thresholds are usually in accordance with "Scheme T" -> > 0.5 GeV && E > 0.8 GeV.
>
>
Even with a fast iterative cone method, the HLT algorithm cannot keep up with the L1 readout unless there's a very high jet energy threshold (1 Hz = 650 GeV (one jet)). Usually you need something else besides the pure jet to have an acceptable rate with an acceptable threshold. Also note that each calorimeter tower corresponds to 1 HCal, and one 5x5 section of PbWO4 ECal pads. Noise elimination thresholds are usually in accordance with "Scheme T" -> > 0.5 GeV && E > 0.8 GeV.
Finally, we must mention the recombination schemes. Since information is stored at the particle level, the jet algorithms eventually need to combine the individual particles' momenta and define the collection of particles as a single "jet" entry. There are two schemes to do this. In all cases, the Jet (particle).
Changed:
<
<
• Single Angle Recombination - (usually used with cone algorithms)
• Vector Recombination - and (usually used with the kT algorithms)
Error during latex2img:
ERROR: problems during latex
INPUT:
\documentclass[fleqn,12pt]{article}
\usepackage{amsmath}
\usepackage[normal]{xcolor}
\setlength{\mathindent}{0cm}
\definecolor{teal}{rgb}{0,0.5,0.5}
\definecolor{navy}{rgb}{0,0,0.5}
\definecolor{aqua}{rgb}{0,1,1}
\definecolor{lime}{rgb}{0,1,0}
\definecolor{maroon}{rgb}{0.5,0,0}
\definecolor{silver}{gray}{0.75}
\usepackage{latexsym}
\begin{document}
\pagestyle{empty}
\pagecolor{white}
{
\color{black}
\begin{math}\displaystyle \eta = \frac{\Sigma_{T,i} \times \eta_{i}}{\Sigma{E_{T}}\end{math}
}
\clearpage
{
\color{black}
\begin{math}\displaystyle \phi = \frac{\Sigma_{T,i} \times \phi_{i}}{\Sigma{E_{T}}\end{math}
}
\clearpage
\end{document}
STDERR:
This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013)
restricted \write18 enabled.
entering extended mode
(/tmp/g6T3qrazXD/ry3mKfCHhH
LaTeX2e <2011/06/27>
Babel  and hyphenation patterns for english, dumylang, nohyphenation, lo
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/fleqn.clo)
(/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the ?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/dvips.def))
(/usr/share/texlive/texmf-dist/tex/latex/base/latexsym.sty)
No file ry3mKfCHhH.aux.
(/usr/share/texlive/texmf-dist/tex/latex/base/ulasy.fd)
! Missing } inserted.

}
l.18 }

[1]
! Missing } inserted.

}
l.23 }

[2] (./ry3mKfCHhH.aux) )
(see the transcript file for additional information)
Output written on ry3mKfCHhH.dvi (2 pages, 904 bytes).
Transcript written on ry3mKfCHhH.log.

>
>
• Single Angle Recombination: (usually used with cone algorithms)
• Vector Recombination: and (usually used with the kT algorithms)

>
>
In all cases, of course, the Jet .

### Online Reconstruction

HLT Algorithm - Iterative Cone. Inputs: R = size of cone, = iteration energy change

This is the fastest cone finding algorithm, which also means that it's the least robust. Offline reconstruction is much more accurate, but this iterative cone works well for a first pass. Also keep in mind that the iterative cone algorithm can take a maximum of 4 jets per event, as that's what the L1 trigger can maximally find. The iterative cone method works by:

• Order a list of all particles in an event by .
• Take a size R cone in and space cast around input object with largest .
• Find the "proto-jet" using all particles in the size R cone using one of the recombination schemes (usually Single Angle)
• Computed direction now seeds new protojet.
• Iteratively step until the proto-jet energy change is less than the desired (usually 1%) and the < 0.01.

### Offline Reconstruction

These next few reconstruction methods are all significantly slower than the iterative cone algorithm, but seem to be significantly more robust, especially in terms of jet splitting and merging. In fact, this area is where the next algorithm thrives.

Midpoint Cone Algorithm - Mid speed. Inputs (size of cone R, jet energy overlap threshold f)

When proto-jets are calculated here, the objects in the proto-jets are not removed from the particle collection, as they were in the iterative cone method. Instead, for each pair of protojets within R, a midpoint is defined. Then, this midpoint is used as a seed to find more protojets. Essentially, what we do is:

• Starting with the highest particle , discover if other particles lie within a distance R of the particle
• If not, then the proto-jet is defined as a jet and we remove this particle from the list
• If yes, then continue
• Looking at our two overlapping proto-jets, we calculate the shared energy between the jets
• If the shared energy > f (f is usually ~50%), the proto-jets are merged.
• Else, the particles are individually assigned to the closest proto-jet in and space.
• This repeats, starting with the proto-jet with the highest remaining , until all jets have been located.

Inclusive Algorithm - Mid speed. Inputs (single particle weight )

This is a cluster-based algorithm, meaning that it does not require a single particle seed to start with, as do the iterative and midpoint cone algorithms. Instead, what we do is we look at all particles in an event, along with all pairs of particles in an event and sort them by isolation. Essentially, the algorithm works like this:

• For each object i and each pair ij, we find:
• , where is a dimensionless weighing parameter, usually equal to 1.
• , where
• If is the smallest, then the object designated as a jet and filled into the jet list.
• If is the smallest, then the objects are merged (usually using the vector recombination method) and re-added to the particle list as a single particle.

SIS-Cone Algorithm - Mid to Slow Speed. Inputs (Cone radius R, iteration steps N)

This is a more complicated algorithm, and one that needs to be looked at further. From what I can understand, this SIS-Cone (Seedless Infrared Safe Cone) is seedless, meaning that the highest particle is not influencing where the jet will likely be. Instead, the algorithm searches for "stable jets," which are jets that have the same direction and energy regardless of whether the particles located on the edge of the cone radius are included or not. It seems to work a little better than the pure Midpoint Cone and the kT algorithms. The general method seems to be:

• For all particles in event
• Find Stable Cones
• Add each stable cone to the list of jet objects
• Remove particles within a stable cone from the candidate list
• Repeat N times or until no new cones are found.

For finding stable cones, the procedure is outlined as such:

• For each particle i
• Find all particles j within a distance 2R of i.
• For each particle j, identify the two circles where i and j lie on the circumference
• Compute angle (in y and space) of each circle's center to the location of particle i. (y = rapidity)
• Call this angle , where
• Sort circles into increasing .
• For all four permutations of including and excluding the edge points i and j
• If cone containing inside particles has not been found (using bitwise XOR to increase speed), add it to the list of cones.
• If the cone momentum is the same with or without the edge points, define it as stable.
• Do this for all circles
• For each stable cone, check explicitly its stability, then add it to the list of proto-jets.

Then, we take our list of proto-jets and apply the midpoint cone algorithm to obtain a list of true jets.

Anti-kT Algorithm - Mid speed. (Inputs: single particle weight )

Anti-kT Algorithm Performance

This algorithm is essentially the same as the kT algorithm, but the method it uses to find the distances and work a little differently. In the algorithm paper, it is shown that the case of using 's work quite well, but it is also shown that using may work even better. In the plot to the right (taken from the anti-kT paper, published here, we find that the anti-kT algorithm has a significantly better jet structure - i.e. the largest jets have the most conical shape, while the smaller jets tend to get mixed with the background. To use this algorithm, we simply have to modify the distances and from the kT algorithm to be:

• , where is a dimensionless weighing parameter, usually equal to 1.
• , where, as before
and follow the same steps as we do in the kT algorithm.

## May 11, 2012

Looked for a long time at Jet Trigger Algorithms today. Found a good summary from this paper:

Page 693:

Changed:
<
<
Jet-finding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-finding trigger based on summing from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisfies the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simplifies the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing of sums, which together with the tower center position are used to calculate various components. Neutrino identification consists in calculation of the missing vector and checking this value by the preset threshold.
>
>
L1 Jet-finding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-finding trigger based on summing from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisfies the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simplifies the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing of sums, which together with the tower center position are used to calculate various components. Neutrino identification consists in calculation of the missing vector and checking this value by the preset threshold.
Gave a presentation today on the L1 trigger spectra and threshold curves. This is located here.
Line: 160 to 234

 META FILEATTACHMENT attachment="cmsSchematic.gif" attr="" comment="CMS Schematic" date="1336932304" name="cmsSchematic.gif" path="cmsSchematic.gif" size="98484" stream="cmsSchematic.gif" tmpFilename="/usr/tmp/CGItemp11175" user="kjung" version="1" attachment="JetTrgAlgo.gif" attr="" comment="Calorimeter Jet Trigger Algorithm" date="1336936981" name="JetTrgAlgo.gif" path="JetTrgAlgo.gif" size="34521" stream="JetTrgAlgo.gif" tmpFilename="/usr/tmp/CGItemp11209" user="kjung" version="1" attachment="L1JetTrgConfig.gif" attr="" comment="L1 Jet Trigger Configuration" date="1336937287" name="L1JetTrgConfig.gif" path="L1JetTrgConfig.gif" size="59888" stream="L1JetTrgConfig.gif" tmpFilename="/usr/tmp/CGItemp11067" user="kjung" version="1"
>
>
 META FILEATTACHMENT attachment="antiKtPerf.gif" attr="" comment="Anti-kT algorithm performance" date="1337097998" name="antiKtPerf.gif" path="antiKtPerf.gif" size="106307" user="kjung" version="1"

#### Revision 42012-05-15 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 14, 2012

The HLT and Reco algorithms are not incredibly complicated, which is nice. I aim to give a nice summary below. We also must remember that the HLT trigger moves the 3 kHz L1 trigger rate down to the ~100 Hz write to disk rate. As an overall theme, if the reconstruction fails or the event is suddenly deemed uninteresting, the reconstruction is stopped at that point and the event is discarded. This includes the HLT and Reco steps.

HLT Jet Finding Algorithm - "Iterative Cone Method."

Even with this fast iterative cone method, the algorithm cannot keep up with the L1 readout unless there's a very high jet energy threshold (1 Hz = 650 GeV (one jet)). Usually you need something else besides the pure jet to have an acceptable rate with an acceptable threshold. Also note that each calorimeter tower corresponds to 1 HCal, and one 5x5 section of PbWO4 ECal pads. Noise elimination thresholds are usually in accordance with "Scheme T" -> > 0.5 GeV && E > 0.8 GeV.

Finally, we must mention the recombination schemes. Since information is stored at the particle level, the jet algorithms eventually need to combine the individual particles' momenta and define the collection of particles as a single "jet" entry. There are two schemes to do this. In all cases, the Jet (particle).

• Single Angle Recombination - (usually used with cone algorithms)
• Vector Recombination - and (usually used with the kT algorithms)
Error during latex2img:
ERROR: problems during latex
INPUT:
\documentclass[fleqn,12pt]{article}
\usepackage{amsmath}
\usepackage[normal]{xcolor}
\setlength{\mathindent}{0cm}
\definecolor{teal}{rgb}{0,0.5,0.5}
\definecolor{navy}{rgb}{0,0,0.5}
\definecolor{aqua}{rgb}{0,1,1}
\definecolor{lime}{rgb}{0,1,0}
\definecolor{maroon}{rgb}{0.5,0,0}
\definecolor{silver}{gray}{0.75}
\usepackage{latexsym}
\begin{document}
\pagestyle{empty}
\pagecolor{white}
{
\color{black}
\begin{math}\displaystyle \eta = \frac{\Sigma_{T,i} \times \eta_{i}}{\Sigma{E_{T}}\end{math}
}
\clearpage
{
\color{black}
\begin{math}\displaystyle \phi = \frac{\Sigma_{T,i} \times \phi_{i}}{\Sigma{E_{T}}\end{math}
}
\clearpage
\end{document}
STDERR:
This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013)
restricted \write18 enabled.
entering extended mode
(/tmp/JmQ_FyJMzj/TQPYj4Dfqc
LaTeX2e <2011/06/27>
Babel  and hyphenation patterns for english, dumylang, nohyphenation, lo
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/fleqn.clo)
(/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the ?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/dvips.def))
(/usr/share/texlive/texmf-dist/tex/latex/base/latexsym.sty)
No file TQPYj4Dfqc.aux.
(/usr/share/texlive/texmf-dist/tex/latex/base/ulasy.fd)
! Missing } inserted.

}
l.18 }

[1]
! Missing } inserted.

}
l.23 }

[2] (./TQPYj4Dfqc.aux) )
(see the transcript file for additional information)
Output written on TQPYj4Dfqc.dvi (2 pages, 904 bytes).
Transcript written on TQPYj4Dfqc.log.


## May 11, 2012

Changed:
<
<
First Entry - Looked for a long time at Jet Trigger Algorithms today. Found a good summary from this paper:
>
>
Looked for a long time at Jet Trigger Algorithms today. Found a good summary from this paper:
Page 693:

#### Revision 32012-05-13 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
Line: 7 to 7
Page 693:
Changed:
<
<
Jet-finding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-finding trigger based on summing ET from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisfies the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simplifies the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of ET from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing ET of sums, which together with the tower center position are used to calculate various ET components. Neutrino identification consists in calculation of the missing ET vector and checking this value by the preset threshold.
>
>
Jet-finding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-finding trigger based on summing from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisfies the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simplifies the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing of sums, which together with the tower center position are used to calculate various components. Neutrino identification consists in calculation of the missing vector and checking this value by the preset threshold.

Gave a presentation today on the L1 trigger spectra and threshold curves. This is located here.

Had an extensive read today on the L1 Jet Trigger Algorithm. Ideally, I'd like to know the entire process from triggering through HLT through reconstruction. Wei then asked me to write an internal Purdue analysis note for the Jet Trigger. The discussion that follows will be enhanced by using the diagrams on the right hand side of the page.

Calorimeter Tower Configuration

L1 Jet Configuration

The Jet Trg. Algorithm uses the in each 4x4 tower section (calorimeter "region"). The Jets are then characterized by the in each 3x3 block of calorimeter regions (12x12 towers). The jets can be defined as " - like" if no veto bits are set in any region. These veto bits are set if there exist > 2 active Ecal & Hcal towers in any region.

Overall, there are 72 towers and 56 towers (|| < 5, full 2 of coverage). 20 regional crates control the individual towers. 18 control the barrel and endcaps (|| < 3), 1 crate from Hadronic Forward Calorimeter (HF) 3 < || < 5, and finally 1 last crate for the regional information from the other crates. This "Master" crate sends the jet/tau candidates with location info and . Tau rejection is nice for jet-tagging as tau events often look just like jets. I don't fully understand how the veto rejection bits work, so I might add this to the to do list (done). The tower size of the HF cal is larger than that of the barrel, such that a 12x12 tower region (in hcal or ecal) corresponds to a 3x3 tower region in the HF cal. The Center of the jet is picked out using a simple algorithm for the 4x4 regions. If the > region to the right and bottom, and the >= region to the left and top, that region is a center region for jets. Finally, the algorithm can keep only the highest 4 energies for central and forward jets, and (I think) the highest 4 energies of central taus. Therefore, up to quad jet triggers are possible.

##### Things left to do:
• Obtain information about the HLT Triggers (Specifically the Jet HLT Trigger Algorithms)
Changed:
<
<
• Figure out how to change the Jet Reconstruction algorithm in the Open HLT framework. Seems like ak5CalCorJets is not a common algorithm for HI.
>
>
• Figure out how to change the Jet Reconstruction algorithm in the OpenHLT framework. Seems like ak5CalCorJets is not a common algorithm for HI.

• Ensure we're doing Heavy Ion reconstruction (not pp reco) when we build the jets using OpenHLT. This needs to be revisited.
>
>
• Further study on the tau veto bits.

## May 2, 2012

Calculating Trigger Efficiency Curves

Need various trigger thresholds to obtain this spectrum. Current ntuple (As of 5/1) only contain 1 trigger threshold. I think the OpenHLT production can be adjusted for any trigger threshold for certain triggers (specifically Jet triggers and EG triggers). Each Trigger Menu (located here) contains a fairly extensive set of triggers, so I decided to build the plots of the efficiency curves for the various triggers that were in the collection. The plots of Ratio of passed events to total events vs trigger threshold can be made, just with only a few points at a time (i.e. Jet 16, Jet 36, Jet 52, etc...). These plots will be shown in a presentation on May 11.

## March 28, 2012

L1 Trigger Algorithm

Mostly written by MIT Students (MIT And Vanderbilt basically run the HI @ CMS.

CMS Working Groups (HI) PinG

• Spectra
• Flow / correlations
• Dilepton
• Jet
• Dimuon

Tracking needs to be improved before charm-tagged jets can be observed.

• Start from p+p -> Move to Heavy Ion?

## March 6, 2012

The CMS Experiment

>
>
Layout of the CMS Experiment

Dimensions

• 21.6 m long
• 14.6 m diameter
Magnet
• 4 T inner field, 2 T return yoke through muon detector
• 13 m long
• 6 m inner diameter
Tracking Volume
• 5.8 m length
• 2.6 m diameter
Design Luminosity
• 25 ns bunch crossing
Inner Tracking System
• < 2.5, efficient to < 2.0

## February 29, 2012

Line: 81 to 147
-- KurtJung - 11-May-2012

 META FILEATTACHMENT attachment="cmsSchematic.gif" attr="" comment="CMS Schematic" date="1336932304" name="cmsSchematic.gif" path="cmsSchematic.gif" size="98484" stream="cmsSchematic.gif" tmpFilename="/usr/tmp/CGItemp11175" user="kjung" version="1"
>
>
 META FILEATTACHMENT attachment="JetTrgAlgo.gif" attr="" comment="Calorimeter Jet Trigger Algorithm" date="1336936981" name="JetTrgAlgo.gif" path="JetTrgAlgo.gif" size="34521" stream="JetTrgAlgo.gif" tmpFilename="/usr/tmp/CGItemp11209" user="kjung" version="1" attachment="L1JetTrgConfig.gif" attr="" comment="L1 Jet Trigger Configuration" date="1336937287" name="L1JetTrgConfig.gif" path="L1JetTrgConfig.gif" size="59888" stream="L1JetTrgConfig.gif" tmpFilename="/usr/tmp/CGItemp11067" user="kjung" version="1"

#### Revision 22012-05-13 - KurtJung

Line: 1 to 1

 META TOPICPARENT name="KurtJung"
>
>

## May 11, 2012

First Entry - Looked for a long time at Jet Trigger Algorithms today. Found a good summary from this paper:

Page 693:

Changed:
<
<
Jet-ﬁnding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-ﬁnding trigger based on summing ET from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisﬁes the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simpliﬁes the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of ET from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing ET of sums, which together with the tower center position are used to calculate various ET components. Neutrino identiﬁcation consists in calculation of the missing ET vector and checking this value by the preset threshold.
>
>
Jet-finding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-finding trigger based on summing ET from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisfies the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simplifies the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of ET from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing ET of sums, which together with the tower center position are used to calculate various ET components. Neutrino identification consists in calculation of the missing ET vector and checking this value by the preset threshold.

##### Things left to do:
• Obtain information about the HLT Triggers (Specifically the Jet HLT Trigger Algorithms)
• Figure out how to change the Jet Reconstruction algorithm in the Open HLT framework. Seems like ak5CalCorJets is not a common algorithm for HI.
• Ensure we're doing Heavy Ion reconstruction (not pp reco) when we build the jets using OpenHLT. This needs to be revisited.
>
>
 March 6, 2012

The CMS Experiment

February 29, 2012

Generating MinBias events from AMPT (impact parameter (b) from 0 to 10)
Needs:
MC Info
Particle Corresponding to each track
Particle ID Distribution

Reco Info
Reco Track <-->
MC track correspondence.
• pT Distribution for each particle
• |eta| for each particle
• pT (Reco) - pT (MC) / pT (MC) vs pT (MC) (Resolution)
• No. of Silicon tracker hits associated with each track for each PID
• Schematic:

Pass generator -> [Virtual Experiment (Geant 4)] -> [MC Info] -> [Reconstruction, based on hit smearing] -> [Reco Hits] -> [Reco Tracks]

## January 30, 2012

GRID Takes care of file finding and shipping

p-Pb Simulation

• Trigger analysis -> which trigger fires and how often
• L1 Trigger
• HLT (not L0 / L1)

To Do

• Study GRID
• Copy any root file - Draw pT, eta, multiplicity spectrum

## January 26, 2012

CMSSW-SW Hierarchy

Collision -> (L1 Trigger + HLT Trigger) -> RAW -> (tracking, vertexing, Particle ID) -> RECO -> (Organization + RECO Summary) -> AOD

PAT - Physics Analysis Toolkit (Pat-tuples)

• Menu in restaurant -> People order different things, but all from the same menu
• Allows easy interaction w/ RECO and AOD data.
• PATs are different depending on physics being analyzed
• Configured using python

cmsRun - Main software module -> extensions are loaded onto main substructure. Usually use cmsRun for creating known data, where FWLite has improved interactivity.

!!TIP!! - Protect #includes with

#if !defined (__CINT__) && !defined (__MAKECINT__) ... #endif

Using FWLite requires the use of fwlite::Handles, which act as branches in TTrees -> Handle.getbyLabel(). edm::EventBase works the same way but integrates into cmsRun.

-- KurtJung - 11-May-2012

>
>
 META FILEATTACHMENT attachment="cmsSchematic.gif" attr="" comment="CMS Schematic" date="1336932304" name="cmsSchematic.gif" path="cmsSchematic.gif" size="98484" stream="cmsSchematic.gif" tmpFilename="/usr/tmp/CGItemp11175" user="kjung" version="1"

#### Revision 12012-05-11 - KurtJung

Line: 1 to 1
>
>
 META TOPICPARENT name="KurtJung"

## May 11, 2012

First Entry - Looked for a long time at Jet Trigger Algorithms today. Found a good summary from this paper:

Page 693:

Jet-ﬁnding algorithm. The jet trigger is based on sums of the transverse energies of electromagnetic and hadron calorimeters in non-overlapping towers 4 × 4 in size (0.35η × 0.35φ region). Simulation has shown that the jet-ﬁnding trigger based on summing ET from 16 trigger towers in the region of 0.35 × 0.35 in the η and φ directions quite satisﬁes the LHC experimental conditions. An adequately acceptable result was obtained for both jets with high momentum pT, generated by standard QCD processes, and jets from decays of SUSY particles with masses above 300 GeV. The relatively small jet regions provide certain advantages for implementation of triggers with many jets, since jets are more easily resolved in the η and φ directions. The jet-trigger region has a 10-bit dynamic range covering energies up to 1000 GeV. The values of local jet sums are sorted according to their transverse sums to obtain the top ranks of jets. Moreover, the jet trigger simpliﬁes the search for isolated τ leptons, which can be produced by decays of MSSM (Minimal Supersymmetric Standard Model) Higgs particles. The data on jet candidates are obtained by simple summation of the values of ET from 16 electromagnetic and 16 hadron towers. The same sums are used as input data for the total and missing energy missing ET of sums, which together with the tower center position are used to calculate various ET components. Neutrino identiﬁcation consists in calculation of the missing ET vector and checking this value by the preset threshold.

##### Things left to do:
• Obtain information about the HLT Triggers (Specifically the Jet HLT Trigger Algorithms)
• Figure out how to change the Jet Reconstruction algorithm in the Open HLT framework. Seems like ak5CalCorJets is not a common algorithm for HI.
• Ensure we're doing Heavy Ion reconstruction (not pp reco) when we build the jets using OpenHLT. This needs to be revisited.

-- KurtJung - 11-May-2012

Copyright &© 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback