Here we will have to document the changes in the 03Feb2017 re-miniAOD and any associated recipes and recommendations. The corresponding code in github is in


When there were multiple AOD datasets for a given era, a version label has been appended to the 03Feb2017 to distinguish between the outputs coming from the different inputs (and which should not be confused with the version of the MINIAOD dataset, the final -v(number) in the name, which is just the number of attempts it took to get the dataset successfully processed by the production system).

  • For Run2016B, you will find 2 datasets called Run2016B-03Feb2017_ver1 and Run2016B-03Feb2017_ver2 ; these map to the RAW Run2016B-v1 and Run2016B-v2
    You can normally skip the ver1 dataset as it does not contain any runs in the golden JSON.
  • For Run2016H, you will find two datasets called Run2016H-03Feb2017_ver2 and Run2016H-03Feb2017_ver3; these map to the PromptReco-v2 and PromptReco-v3 AODs.
    You should use both datasets, as they do not overlap.


READ THIS: It would be extremely advisable to store the bool particleFlowEGammaGSFixed:dupECALClusters and if ecalMultiAndGSGlobalRecHitEB:hitsNotReplaced is empty or not in any analysis job. If particleFlowEGammaGSFixed:dupECALClusters = true or ecalMultiAndGSGlobalRecHitEB:hitsNotReplaced is not empty, the fix may not have worked for that event and it needs to be manually recovered or at least scrutinized further. This events should be extremely rare but are possible. If you want to save which objects had a gain switch in at least one of its hits, see the userInts in this section.

The standard collections store the objects after the ECAL slew rate mitigation . We also store the old collections for comparison. A technical description of the changes can be found in a dedicated wiki.

With mitigation Original collection
slimmedElectrons slimmedElectronsBeforeGSFix
slimmedPhotons slimmedPhotonsBeforeGSFix
reducedEgamma reducedEgammaBeforeGSFix

Short Description of E/gamma Collections

This only details the fixed collections. To get the original collections add "BeforeGSFix" to the producer name as shown above.

name notes
slimmedElectrons all barrel electrons have supercluster updated to the reclustered one, only electrons with a gain switched crystal in the 5x5 of the seed crystal have their energies and showershapes updated
slimmedPhotons all barrel photons have supercluster updated to the reclustered one, only photons with a gain switched crystal in the 5x5 of the seed crystal have their energies and showershapes updated
reducedEgamma:reducedEBEEClusters the fixed ECAL clusters comprising the superclusters of the slimmed electrons and photons. Endcap clusters are copies of the original while barrel clusters are reclustered (except when the barrel refined supercluster has no parent supercluster).
reducedEgamma:reducedESClusters the preshower clusters associated to the superclusters of the electrons and photons. These are copies of what was originally in the miniAOD.
reducedEgamma:reducedGedGsfElectronCores the electron cores of the slimmedElectrons which contain references to the superclusters that have been gain switch fixed if appropriate
reducedEgamma:reducedGedPhotonsCores the photon cores of the slimmedPhotons which contain references to the superclusters that have been gain switch fixed if appropriate
reducedEgamma:reducedConversions the conversions linked in the slimmedElectrons and slimmedPhotons objects are the same as in the original objects, ie not gain switch fixed! (this was for technical reasons)
ecalMultiAndGSGlobalRecHitEB:hitsNotReplaced its not guaranteed that all GS hits are in the AOD, this collection has the DetId of all hits which were in the barrel, had a GS but could not be replaced. Should be empty, if you find it non-empty for your events, re-reco it from the RAW.
particleFlowEGammaGSFixed:dupECALClusters it is possible for the same supercluster (or cluster) to be added to the event multiple times. We think we got all the cases this happens but can not guarantee it. This is a bool indicating if this happened, if this is set to "true" the event needs further scrutiny.

Key Caveats with the Fix

This fix is mostly but not completely transparent to the user. Some small things changed. Read this section for detailed information on all the caveats associated with the fix.

First, if something is unclear, please help us improve the documenation by email your query to

Second, this information is a copy of EcalSlewRateMitigation#Key_Points_to_be_Aware_of

  1. Barrel refined superclusters are always remade, even if there is no gain switch
  2. The energy and showershape of a electron/photon is only remade if there is gain switched crystal in the 5x5 area centred on the seed crystal
  3. Issues 1) and 2) mean that the energy of the supercluster may be not be fully consistent with the electron/photon energy/showershape when its non-gainswitched, this is thought never to happen but be warned
  4. The fiduical flags of electrons and photons are not updated and reflect the seed crystal of the old supercluster. This is by construction within +/-1 crystal of the new supercluster. The impact of this should be extremely small but be warned.
  5. It is possible for a gain switched crystal not to be in the selectedEcalDigis and therefore not replaced. This happens extremely rarely. The collection "ecalMultiAndGSGlobalRecHitEB:hitsNotReplaced" has the DetIds of all effected hits and users should check that it empty for their events. If it is not, it indicates a possible problem and the event should be further scrutinised. To give a sense of scale, in the entire Z' analysis, we found 18 such events, all at the Z peak.
  6. It is theoretically possible for this effect to split a barrel supercluster into two. In this case the new merged barrel supercluster matches to both of the orginal superclusters and gets added in twice. These events are passed through but are flagged by a bool, "particleFlowEGammaGSFixed:dupECALClusters" which users should explicity check. If true, it means duplicate basic clusters were added into the event and further scrutiny should be applied to the event as it may have duplicated electrons and photons. We currently know of no events where this occurs as we fixed all the cases where it did happen.
  7. Orphan refined superclusters are not remade and simply passed through. This should have little practical consquence but it does mean that its subclusters are the orginal PFClusters and not gain switch fixed. It is hard to imagine a senario where a high energy electron / photon has just an orphan supercluster. This also means that things are not completely consistent in this case but again is thought to have little practical effect
  8. Particle flow is not re-run and it may be instances of corrected electrons/photons that would fail PF identification when the original one passed (or vice-versa). Those cases are rare, but it's a possibility.
  9. More on particle flow objects: even though they are linked correctly to the new superclusters, the energy of the PFelectrons and PFphotons is not corrected!
  10. Due to technical reasons, the supercluster that the conversion links to is the one in the old electron. Be careful when using them, if you need to refer back to the supercluster. The problem is the following: while it's not hard to remap the conversions, it's impossible to replace the conversions inside the GsfElectron object. And, at the same time, we cannot make a new collection, because we don't have the track collection in AOD.
  11. E/gamma only fixed the E/gamma objects. We did not propagate this input to other POGs, specifically taus and b-tagging.


Expert Information

Users can check if an electron or a photon has a crystal in the EB with gain switch by using the following test:

electron.userInt("hasGainSwitchFlag") == 1;
photon.userInt("hasGainSwitchFlag") == 1;

We do not store a map between objects before and after the mitigation in miniAOD. The matching can be done via the ID of the seed crystal with this type of test:

electron.superCluster()->seed()->seed().rawId() == oldelectron.superCluster()->seed()->seed().rawId();

In rare occasions, it is possible that a cluster had a crystal with gain switch but we did not have the DIGI in AOD to mitigate the problem. We save the collection of DIGI used in the mitigation code, so that expert users can check if this rare situation can have an impact in their analysis. They are saved as (selectDigi, selectedEcalEBDigiCollection) and (selectDigi, selectedEcalEEDigiCollection). In the case an expert user would like to perform this advanced check, we provide a function that returns the list of detId with gain switch problems in this function.

Muons and PF Candidates

In this re-miniAOD, the filters for bad and duplicate muons advertised on physics-validation/2786 are used.

Event flags:

Three flags are saved in the event:

  • Flag_badMuons: the event contained at least one PF muon of pT > 20 GeV that is flagged as bad
  • Flag_duplicateMuons: the event contained at least one PF muon of pT > 20 GeV that is flagged as duplicate
  • Flag_noBadMuons: the event does not contain any PF muon of pT > 20 GeV flagged as bad or duplicate (i.e. the event is safe)
They can be accessed from the TriggerResults just like the other MET filters.


The slimmedMuons collection contains all muons, as before.

However, the muons flagged as bad or duplicate are now no longer marked as PF muons; thus, isPFMuon() will return false on them (and consequently also isLooseMuon, isTightMuon, etc.). Nothing else of the muon is changed (e.g. the 4-vector is as given by the particle flow)

You can access the old value of the PF id flag via muon.userInt("muonsCleaned:oldPF") . If you want to make the muon PF again, you can copy it by value and then do muon.setType(muon.type() | reco::Muon::PFMuon).

ParticleFlow candidates & PUPPI weights

The bad and duplicate muons are removed from the packedPFCandidates list, and put in a separate collection packedPFCandidatesDiscarded; thus, the sourceCandidatePtr for bad or duplicate slimmedMuons= will therefore point to that second collection.

The PUPPI weights are computed from the cleaned PF candidates. The discarded PF candidates do not have a valid PUPPI weight.

Edit | Attach | Watch | Print version | History: r19 | r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r11 - 2017-02-13 - NickAmin
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback