Compilation issue with NtupleProducer/plugins/BuildFile.xml and NtupleProducer/BuildFile.xml: the CMMSW version can't be parsed anymore from shell commands for some reason. A quick and dirty fix is to hardcode it, replacing

  <Flags CPPDEFINES="CMSSW_VERSION=$(shell echo ${CMSSW_VERSION}|sed -e s/CMSSW_// -e s/_//g -e s/patch\.//)"/>

with

<Flags CPPDEFINES="CMSSW_VERSION=$(10627)"/> 

but there should be a cleaner way to avoid the issue.

To port modifications on mva electron id

• and maybe git pull will finally work now :-)

In some cases the sync requires trigger paths with same name to match different filters
(e.g. the same path has different filters for Run B/C and run D data).
The current logic of the trigger matching must be checked to ensure this is correctly done.

Following variables must be added:

self.Jet_leadTrackPt = array.array('f',[0])
self.Jet_leptonPtRel = array.array('f',[0])
self.Jet_leptonPt =  array.array('f',[0])
self.Jet_leptonDeltaR = array.array('f',[0])

self.Jet_vtxPt = array.array('f',[0])
self.Jet_vtxMass = array.array('f',[0])
self.Jet_vtx3dL = array.array('f',[0])
self.Jet_vtxNtrk = array.array('f',[0])
self.Jet_vtx3deL = array.array('f',[0])

# The following could already be stored, to check
self.Jet_rawPt = array.array('f',[0])
self.rho = array.array('f',[0])
self.Jet_mt = array.array('f',[0])

Check here for variables usage and possible definitions:
https://github.com/vhbb/cmssw/blob/vhbbHeppy74X/VHbbAnalysis/Heppy/python/JetRegression.py

Adapt the ntuplizer to include all sync exercise branches.
See https://twiki.cern.ch/twiki/bin/viewauth/CMS/HiggsToTauTauWorking2015#Synchronisation_Ntuple

Title says all!
Simply add the recipe contained here:
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideMETSignificance#Instructions_for_7_2_X
(now the usage of simple pfMET instead of MVA MET will crash due to the lack of covariance matrix in minAOD)

We need to include all the needed variables. Here is a temptative list:
Leptons:
-mothers/daughters 4-momenta (DONE)
-referencing mother/daughter (DONE)
-pdg (DONE)
-lepton quality?
e/mu/taus single collections (for vetos) (DONE)

JET:

• all jet 4-momenta (DONE)
• b tagging CSV score value (DONE)
• number of jets (DONE)
• number of jets b tagged (or we save all jets?)=>(DONE, save all)

TAUH: (DONE)

• ISO tauh (tightestHPSMVA3oldDMwLTWP (DONE)
• decay mode from HPS algorithm (DONE)

MET:

• METMag
• METPhi
• ...

OTHER:
-eventnumber (DONE)
-run (DONE)
-trigger bit (DONE)

• flags veto on additional e/mu/tauh ? Or we leave it to analysis? (DONE=> leave to analysis)
• SVFitMass (this belongs to another issue)

Before production, check if MET filters are still up to date

Create the TauFiller and put in the following flags:

• MVA tau isolation
• Isolation
• Other possible flags?

Prepare a set of global variables to cut on leptons/collections, so that one does not have to go through the code for that

The following issues with the SVFit module have to be addressed:

The following message happens in several occasions (both for ele and muons):

• Warning: tau -> electron decay declared for leg: Pt = 18.982, eta = -1.20233, phi = 0.637383, mass = 0.0126532 !! (mass expected in the range = 0.000511..0.000511)
  This is clearly due to leptons with mass different from pdg mass in the PF (many ele, a few muons).
  Why does not SVFit works with those? Should we put FSR in to improve? Should we ignore it?

SVFit crashes for tau/tau candidates

The SVFit mass is always 0!

The Covariance matrix is 0 (for now we hardcoded a new one). Why? Is it available in miniAOD?

Produce event MEt, pair-related, to be used in the SVfit algorithm

From here: https://twiki.cern.ch/twiki/bin/view/Main/GlobalTags

process.load("Configuration.StandardSequences.FrontierConditions_GlobalTag_condDBv2_cff")
# New Tag format for 2015, also ::All no longer required 
Tag = '74X_dataRun2_Prompt_v1'

• Update the globaltag before processing Moriond17 MC.
  Globaltag list is here:
  https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideFrontierConditions#Global_Tags_for_PdmVMCcampaignRu

• Update electron MVA ID to the latest POG recipe: https://hypernews.cern.ch/HyperNews/CMS/get/higgs2e2nu/733.html

• Update JEC (probably will be available before Christmas)

• Update tau MVA ID as soon as the Tau POG completes the re-training on the latest MC samples

Create SS lepton pairs. Possibly a different collection, possibly with different cuts wrt OS collection

Create a collection of filtered MC objects and store their properties:

• pdgId
• p4
• flags saying if they come from e.g. an Higgs

Create lepton couples (OS/SF) from the miniAOD

Things to check :

• global tag: now using 76X_mcRun2_asymptotic_v13
• consumes on vector on input tag for MVA met (1 met per pair)
• event counters
• noHFMet: apparently slimmedMETsNoHF collection not existing in 76X samples
• MVA MET: 1) need to pick two commits fro the consumes migration 2) crashes with CRAB for sandbox size [should be fixed by removing .git folder, but still untested]

Surely Giacomo will freak out (an issue!!) but this is important as all new tau discriminators are not currently saved. If I write it on my post-it it will remain one week there alone so here's the issue.

Vectors are already available:
https://github.com/LLRCMS/LLRHiggsTauTau/blob/master/NtupleProducer/plugins/HTauTauNtuplizer.cc#L305

And the new names are here (look at the updates in tauFIller):
96312fa

ENHANCEMENT: Discriminators are becoming quite a lot, should we consider to store those that are boolean as bits of a single variable?

Update SVfit bypass to store METx, METy also for the MVA met (currently it is simply taking the first entry of the MET vector). Will be useful when testing the MVA MET, but it is not critical.

Make an ntuplizers to translate informations available in the lepton pairs into ntuple format

Float precision used for daughters_ branches (and maybe mothers_ as well) causes the mass values computed downstream using TLorentzVector to be different from the original value.
Probably not an issue because nobody uses the mass as a variable, but appears as differences in the synchronization. Note that this does not affect SVFit computation.
To be changed to double after the rest of the downstream codes are ready to handle vectors of doubles.

New branch started with name '80X'.

• disabled external JEC
• disabled jet PU ID updated
• updated globaltag
• does not run using MVA MET (PR for 80X cms-met/cmssw#12 not yet merged into CMSSW, no recipe available using usercode)

All modifications to be tested.
To decide later whether keeping two separate branches for 76X and 80X (double work to maintain) or merge this one into the master (requires no compiled code differences between the two releases).

We need to apply leptons corrections, as soon as official recipes appear from the POGs.
For taus, the following was asked from Cécile:

• collection of taus with TES up or down, and their corresponding MET and SV mass (not for now, we wait for the new TES)

Produce a tag and baseline code for the enriched miniAOD

Make an analyzer to operate on the lepton couples from the miniAOD (e.g. cuts)

Some issues showing up during framework tests:

General behaviour

• Large memory usage, exceeds 2Gb for ~40000 evts (~1 miniAOD file size); tested on local tier3, memory usage not decreased even when SVfit and MVA MEt disabled

UPDATE: some problems with vector clearing fixed, Enriched miniAOD production runs fine on GRID now (just pay attention to the max job lenght that is about 23h).
Nutplizer still has some memory problems as memory increases but we can process ~500000 events locally without finishing the memory (very fast, takes < 5 minutes), so it is not a big issue

Ntuple content

• [FIXED 👌 ] Sometimes quarks branch not filled --> status requirement (status ==2 || status ==3) in bFiller fails for some (but not all) PHYS14 samples where b status code is > 10 (pythia8 status code?). Can depend on the generator used? ==> implement the search of the last decay element "by hand" to avoid duplicates of the same particle due to showering process
• [FIXED 👌 ] Same particle can be replicated in daughters branch with different pdg ID (e.g.:
  num - pT | pdgId
  0 93.643 | type: -13
  1 14.3318 | type: -11
  2 10.8532 | type: 11
  3 93.643 | type: -15
  4 23.0021 | type: 15
  )
  UPDATE: only tau are "clones" of either electrons or muons, the clone already exists in the bare* collection (input of *filler.cc) ==> problem of PATTauRefSelector, or even slimmedTaus?
  ===================== MU FILLER =============================
  0 Mu pdgID: 13 pt: 15.5237
  ============================== ELE FILLER ====================
  0 Ele pdgID: 11 pt: 46.5768
  1 Ele pdgID: 11 pt: 43.6879
  ================ TAU FILLER ====================
  0 Tau pdgID: 15 pt: 43.6879

UPDATE: duplication is already present at miniAOD level (slimmedTaus given as input to tauFiller.cc)

UPDATE: only taus having decayMode = 0 (1 charged pi) are duplicated ==> duplication from PF output?

UPDATE: probably due to the missing tau filtering, see https://twiki.cern.ch/twiki/bin/view/CMS/HiggsToTauTauWorking2015#Trigger_Information

UPDATE: this is due to the fact that also muons and electrons are given as an input to the hps algorithm to increase the efficiency, so the duplication is an expected behaviour

• [FIXED 👌 ] Higgs "copies" can appear in some files (e.g. HH generated by Giacomo) --> save just one "clone", first or last? What is modified along the chain? [probably other radiation in the event, other first elements of the chain have always exact pT conservation] ==> I would save the last element
  idx | ID - Name |Stat| Mo1 Mo2 Da1 Da2 |nMo nDa| pt eta phi | px py pz m |
  2 | 25 - h0 | 22 | 0 1 4 4 | 2 1 | 62.797 -0.042 -0.694 | 48.265 -40.173 -2.666 125.000 |
  3 | 25 - h0 | 22 | 0 1 5 5 | 2 1 | 62.797 1.927 2.447 | -48.265 40.173 211.154 125.000 |
  4 | 25 - h0 | 44 | 2 2 6 6 | 1 1 | 71.281 0.289 -1.151 | 29.072 -65.083 20.855 125.000 |
  5 | 25 - h0 | 44 | 3 3 7 7 | 1 1 | 121.511 1.484 -2.770 | -113.217 -44.122 254.293 125.000 |
  6 | 25 - h0 | 44 | 4 4 8 8 | 1 1 | 39.422 0.126 -1.118 | 17.230 -35.458 4.970 125.000 |
  7 | 25 - h0 | 44 | 5 5 9 9 | 1 1 | 122.415 1.471 -2.883 | -118.353 -31.273 252.275 125.000 |
  8 | 25 - h0 | 44 | 6 6 10 10 | 1 1 | 21.790 -0.020 -1.444 | 2.752 -21.615 -0.433 125.000 |
  9 | 25 - h0 | 44 | 7 7 11 11 | 1 1 | 127.168 1.464 -2.942 | -124.633 -25.269 260.301 125.000 |
  10 | 25 - h0 | 44 | 8 8 12 12 | 1 1 | 21.448 -0.009 -1.448 | 2.630 -21.286 -0.194 125.000 |
  11 | 25 - h0 | 44 | 9 9 13 13 | 1 1 | 127.422 1.464 -2.954 | -125.185 -23.772 260.694 125.000 |
  12 | 25 - h0 | 44 | 10 10 14 14 | 1 1 | 24.143 0.010 -1.513 | 1.401 -24.103 0.242 125.000 |
  13 | 25 - h0 | 44 | 11 11 15 15 | 1 1 | 128.180 1.464 -2.945 | -125.719 -24.997 262.330 125.000 |
  14 | 25 - h0 | 44 | 12 12 16 16 | 1 1 | 22.120 -0.006 -1.500 | 1.568 -22.064 -0.133 125.000 |
  15 | 25 - h0 | 44 | 13 13 17 17 | 1 1 | 127.939 1.464 -2.952 | -125.647 -24.110 261.756 125.000 |
  16 | 25 - h0 | 62 | 14 14 18 19 | 1 2 | 21.787 -0.008 -1.491 | 1.729 -21.718 -0.176 125.000 |
  17 | 25 - h0 | 62 | 15 15 20 21 | 1 2 | 127.564 1.466 -2.954 | -125.328 -23.776 261.668 125.000 |
• Need for duplication of PDGIdDaughters and ParticleType? (same information, second is an enum) ==> ask @giacomoortona
• Define a gen lepton flag "isTauPrompt" to tell if it comes from a tau decay in association to the neutrino(s) [e.g. tau -> nu_tau + nu_e + e] or inderectly from other tau products [e.g. tau -> pi0 pi+ that subsequently produce a e+e-]

How do we store trigger objects? Which ones do we want to store?
From Cécile:
We need to store trigger objects or trigger matching.
if the last filter of the trigger path has been fired (check if the trigger object is associated to the last filter, We had some problems in the synchronization in Run1 because some groups did not require the trigger object to be associated to the last filter)

List of objects to be added in the output (fetch from miniAOD):

• PUPPI MET (for the moment, simply store and not use in SVfit)
• boosted jets

Needed to run on Silver json. Of course this MET must also be used as input for the SVfit computation.

From R. Manzoni. I think best solution is to save L1 objects and have them available once for all in subsequent steps. Maybe already perform this check at LLRNtuple level to just have a bool to check in later phases.

Hi,

as it’s been presented in the past [*] for run 2015D we decided to seed our di-tau HLT with two different L1 seeds
L1_DoubleTauJet40er OR L1_DoubleIsoTau28er

including either two isolated taus with pt 28 or two relaxed taus with pt 40.

This was deployed in the menu, but, during the data taking, the relaxed tau seed L1_DoubleTauJet40er got masked by mistake.
Unfortunately we noticed this problem only when the data taking was over.

The whole seed masking management is carried out by L1 shifters and it is a bit opaque to non L1 experts and very error prone, according to the experts themselves
Visually, the masking is represented as regular typeface in place of a bold typeface in WBM [**], and the DQM plots are not fine grained enough (nor it can be) to show a problem as this.

In practise, L1_DoubleTauJet40er was firing but it was not passed to the HLT, as if it wasn’t used at all to seed di-tau HLT for the data taking.
This issue is not present in MC.

I am in the process of measuring the trigger efficiency with 76X samples and assessing the impact of this problem.
My guesstimate is a loss in the ballpark of 5% to 10% per tau leg at plateau, less so for not-so-high pt.

In order to align the MC to the data, you should ask your taus to match with IsoTau L1 extra objects [***] and require these L1 objects’ pt to be larger than 28 GeV.

Cheers,
Riccardo

[*] slide 9
https://indico.cern.ch/event/467387/session/0/contribution/14/attachments/1206615/1759781/htt_workshop_17_12_2015.pdf

[**]
https://cmswbm.web.cern.ch/cmswbm/cmsdb/servlet/TriggerMode?KEY=l1_hlt_HI_Collisions/v59

[***]
vectorl1extra::L1JetParticle "l1extraParticles" "IsoTau" "RECO"

Additional SV fit variables available when using MarkovChain integration.
Add conrresponding userfloats and branches in the ntuplizer

pt_sv, eta_sv, phi_sv, met_sv (algo.pt(), algo.eta(), algo.phi(), algo.fittedMET().Rho())