cjlst/zzanalysis

ZZAnalysis

This is the CJLST framework for analysis of Run 3 data.

To install a complete CMSSW 13X area (including this package)

Used for analysis of 2022 data and beyond

Please use CMSSW_13_0_16.

Download and execute the setup script:

cmsrel CMSSW_13_0_16
cd CMSSW_13_0_16/src
cmsenv
wget -O ${TMPDIR}/checkout.csh https://raw.githubusercontent.com/CJLST/ZZAnalysis/Run3/checkout_13X.csh
chmod u+x ${TMPDIR}/checkout.csh
${TMPDIR}/checkout.csh
scramv1 b -j 4

To update this package from the release

In the package directory, simply issue

git pull

To commit and push new changes

To commit directly (you need write access to the repository):

git pull
[edit files]

Once you are ready to commit

git pull
git add [files to be added]
git commit -m ["commit message"] [files to be added]
git push origin Run2Legacy

Otherwise you can make a fork of the repository, develop therein, and make a pull request in the same way as for CMSSW.

Code documentation

Please see the gitHub wiki for more documentation.

zzanalysis's Issues

Announcing a new set of trees for data.

This production reflects the status of the miniAOD_74X branch on November 18th 2015.
It includes all of 2015 data (Silver JSON file of November 13th). MC will be submitted later.
The trees can be found in the 151119/ directory, under the usual path.

Announcing a new set of trees

This production reflects the status of the miniAOD_76X branch on February 22nd 2016, commit fa73ee0.
It includes in particular all lepton momentum scale corrections and lepton efficiency scale factors.
Only the H(125) signal, ZZ background and data are processed. A complete tree production will follow when JECs are implemented.
The trees can be found in the 160222/ directory, under the usual path.

[NanoAnalysis] Store best cand idx separately for the fiducial analysis

Add the index for the best candidate selected by Z1/Z2 so that the same production can be used for both the "regular" analysis and the fiducial one. This requires:

• adding indices for SR and CR: bestCandByZIdx, ZLLbest2P2FByZIdx, ZLLbest3P1FByZIdx, ZLLbestSIPCRByZIdx, ZLLbestSSByZIdx
• remove the parameter bestCandByMELA which would no longer be relevant.
• Handle the case where runMELA == False: ideally one would have to skip writing bestCandIdx and keep only bestCandByZIdx , but this would complicate things and possibly break scripts downstream that expect these variable, so probably the easiest thing is to set both variables with the byZ selection. (The same need to be done for the CR variables)
• Rework the "candidate suppression" for StoreOption.BestCandOnly: it would need to keep candidates belonging to both indices, if different
• Add the additional CR candidates if needed: it would be enough to add the proper selection here

Prior to this, it may be a good idea to revisit the need to have two different best candidate selection criteria.

• We should recheck how sub-optimal is the byZ criterion for associate production:"it was found to often pick the wrong set of leptons in leptonic ZH and WH events; we should check how often a candidate with a lepton not coming from the H is selected in case where all leptons from H are reconstructed.
• We may try to find better criteria that are based on kinematics that can be defined for the fiducial analysis so that they work in both cases.

Wrong ZX yield using run_yield

Most likely this bug can be fixed adding stage1 categories here: https://github.com/CJLST/ZZAnalysis/blob/Run2_CutBased/AnalysisStep/test/Plotter_v2/src/Yields.cpp#L232
This is how the ZX yield is computed in the SS method: https://github.com/CJLST/ZZAnalysis/blob/Run2_CutBased/AnalysisStep/test/ZpXEstimation/src/SSmethod.cpp#L164-170

Encounter an error

An error arise. what's up???

Plotter_v2/run_combination.cpp:155:25: error: no matching function for call to 'Plotter::PlotM4l()'
combination->PlotM4l();setTDRStyle();
^
In file included from /afs/cern.ch/user/r/repan/CMSSW_10_2_15/src/ZZAnalysis/AnalysisStep/bin/../test/Plotter_v2/run_combination.cpp:17:0:
/afs/cern.ch/user/r/repan/CMSSW_10_2_15/src/ZZAnalysis/AnalysisStep/test/Plotter_v2/include/Plotter.h:83:9: note: candidate: void Plotter::PlotM4l(int)
void PlotM4l( int );
^~~~~~~
/afs/cern.ch/user/r/repan/CMSSW_10_2_15/src/ZZAnalysis/AnalysisStep/test/Plotter_v2/include/Plotter.h:83:9: note: candidate expects 1 argument, 0 provided

Fix root files luminosity number

Fix for the DATA samples at 8 TeV and propagate everywhere in the code
From 19630 To 19712

Add branches for fiducial analysis

After looking back at the analysis code, I think the list of essential branches needed to run the analysis are the following:

        b_sig = ['EventNumber','GENmass4l', 'GENlep_id', 'GENlep_MomId',
                 'GENlep_MomMomId', 'GENlep_Hindex', 'GENZ_DaughtersId',
                 'GENZ_MomId', 'passedFiducialSelection_bbf', 'PUWeight', 'genHEPMCweight']

Of course, besides the branches corresponding to the observable to be measured (for the early Run3 only mass4l and we already have it).

The above variables were defined in GenFiller.cc and it should be straightforward to implement them in the new genFiller.py.

• GENlep_Hindex should already be in there as FidZZ_Z*Idx
• GENlep_id is straightforward, as it's the idx of the lep_dressed we put in Leptons
• GENlep_MomId and GENlep_MomMomId again from Leptons in the new code, we should be able to access this with Mother in tools.py. However we should check if the latter is accessible also in nanoAOD, as it may be that the info has been reduced (ie not sure if mother-of-mother info is still retained).
• GENZ_MomId and GENZ_DaughtersId are currently not accessible straightforwardly, as I did not implement the block on gen-level Zs in the new code

PS: Maybe in nanoAOD there're even smarter ways of accessing these indices than what we did before.

PPS: Not related to this issue, but given the complexity of the code where these indices are used (ie to compute coefficients for the differential analysis) I even wonder if we should rewrite that code from scratch.

Announcing a new set of trees.

This production reflects the status of the miniAOD_74X branch on October 27th, 2015.
The trees can be found in the 151029/ directory, under the usual path.

Change indices to short

To be consistent with nanoAOD and to reduce memory consumption, define as "S" all the indices saved to ntuples.

Announcing a new set of trees

This production reflects the status of the miniAOD_76X branch on February 24th 2016. It is supposed to include all needed ingredients to produce the results for Moriond 2016, in particular lepton momentum scale corrections, lepton efficiency SF, 76X JEC, YR4 signal cross-sections, PU weights.

All MC and data samples are processed; a few missing MC jobs will be merged later today.
Due to a bug in the EWK K-factor, the ZZ4l samples will be replaced.

The trees can be found in the 160225/ directory, under the usual path.

Announcing a new set of trees

This production reflects the status of the miniAOD_76X branch on February 3rd 2016.
No major changes: a few more signal mass points, updated refitted mass error, temporary ZH cross sections, and electron ID information for CR studies.
The trees can be found in the 160203/ directory, under the usual path.

Implement lepton-jet cleaner

Implement cleaning of jets with the candidate's leptons and FSR photons.
This should in principle be equivalent to JetsWithLeptonsRemover, except that the latter is a mess, eg; FSR are matched twice with different requirements; the logic should be streamlined.
The cleaning should be applied afer JEC/JER, but can happen in the same jetFiller module.

7 TeV

To be prepared the setup script for the 4X release release (e.g. 7 TeV sample).

analyzer_2011.py fix

Change primary tree name:
jhuGenV3Vec1MH125.6 --> powheg15jhuGenV3Vec1MH125.6

[AnalysisStep] Memory leak

There is a per-event memory leak here:

ZZAnalysis/AnalysisStep/plugins/JetFiller.cc

Line 183 in ab6f5ba

splittedUncerts_.push_back(new JetCorrectionUncertainty(corrParams));

as new JetCorrectionUncertainty instances are not cleaned up at the end of the loop.

Announcing a new set of trees

This production reflects the status of the miniAOD_76X branch on January 28th 2016. The main changes and additions wrt. the previous production are the new isolation, the refitted m4l and the jet energy corrections.
The production includes all 76X data and MC, except most ggZZ which repeteadly fails, this is a under investigation.
The trees can be found in the 160128/ directory, under the usual path.

Announcing a new set of trees

This production reflects the status of the miniAOD_76X branch on January 21th 2016.
It includes all the 76X MC that is uncommented in this file: https://github.com/CJLST/ZZAnalysis/blob/7df290351b857d50cfbdc2c44176b2a7a167fcb0/AnalysisStep/test/prod/samples_2015.csv (no data).
The trees can be found in the 160121/ directory, under the usual path.

m4l cut in secondary tree production

Relax the m4l cut in the secondary tree production from 100 to 70.

https://github.com/CJLST/ZZAnalysis/blob/master/AnalysisStep/test/Macros/HZZ4l.C#L611

[NanoAnalysis] Refactor overallEventWeight

• Move overallEventWeight to ZZCand_overallEventWeight (and similar for CRs) so that it becomes a candoidate's property, and can include also ZZCand_dataMCWeight
• Move the computation of _dataMCWeight to weightFiller, so that it can be computed with the same code for SR and CRs and only for selected candidates

Bug in ZZ candidate leptons assignment

I believe the getLeptons function has a bug:

• The four leptons found are different if one defines leps = list(electrons) + list(muons) or leps = list(muons) + list(electrons) and this is an undesired behavior.
• For events with more than 4 leptons in total, sometimes we end up selecting the wrong four leptons.

Example (EventNumber==4057199 from /store/mc/Run3Summer22EEMiniAODv4/ZHto2Zto4L_M125_TuneCP5_13p6TeV_powheg2-minlo-HZJ-JHUGenV752-pythia8/MINIAODSIM/130X_mcRun3_2022_realistic_postEE_v6-v2/30000/6fdd2d9e-7213-4815-b37d-b3dfc6a5cdb5.root):

• In miniAOD this is a 2e2mu event, with the following four leptons:

• in nanoAOD with the current implementation of getLeptons we get the following 4 leptons:

with the initial collection of Electron and Muon being:

so we end up selecting the first two leptons (electrons) correctly (they are at ZZCand_Z1l1Idx and ZZCand_Z1l2Idx 1 and 0, respectively), but the third and fourth leptons (muons) are wrong (we have ZZCand_Z2l1Idx and ZZCand_Z2l2Idx being 3 and 4, respectively).

Is this a bug with getLeptons or with the assignment of the ZZCand_Z2l1Idx and ZZCand_Z2l2Idx indices?

@namapane do you have any suggestion?

MC csv files for 2017 94x samples

The RunIIFall17MiniAOD-94X_mc2017_realistic_v10-v1 and v2 tags are outdated in some samples. These tags need to be updated in the following precedence according to availability:

• RunIIFall17MiniAODv2-PU2017_12Apr2018_new_pmx_94X_mc2017_realistic_v14-v1 (only a few samples have this tag)
• RunIIFall17MiniAODv2-PU2017_12Apr2018_94X_mc2017_realistic_v14-v1 (3K+ samples have this tag in DAS)
• RunIIFall17MiniAOD-94X_mc2017_realistic_v10-v3 (none of the samples in the csv files have this tag)
• RunIIFall17MiniAOD-94X_mc2017_realistic_v10-v2 (some of the samples in the csv files already have this tag, but better to check if any other samples need this, or if they need to be replaced with v3 instead)

RFE: split up code, data, batch-related (CERN: AFS vs EOS)

Dear ZZAnalysis maintainers,
we have a report that this package forces the user to submit local batch jobs from the same area that has the code, input data, and will receive output data.
At CERN, this requires these users to have AFS workspace, which is in general no longer needed for CMS users. In particular, installing this package on EOS does not allow to run local batch jobs.
Could you please confirm, and

• if so, implement changes that allow to separate code, input+output data (on EOS) and submit file/log area (on AFS)
• if not, document (or point me to existing documentation) how users can achieve such a split?
  Thanks in advance,
  jan (CERN AFS support)

WWZ_4F_TuneCP5_13TeV-amcatnlo-pythia8

Per PR #64, if you would like to get the correct PDF variations in the /WWZ_4F_TuneCP5_13TeV-amcatnlo-pythia8/*/MINIAODSIM samples, you would need to re-run them. The central PDF was recognized incorrectly, so PDF variations were incorrect as a result. In the CJLST framework conventions, you would not get variations while you should have.