fix to KineParticleFilter::acceptParticle

[missirol]

PR description:

This PR is meant to fix a problem in a Jet/MET analysis workflow.

The current procedure to derive the so-called PF-Hadron Calibrations (for Offline and HLT) relies on the PFSimParticleProducer, which in turn makes use of PFSimBaseEvent and related utilities.

For a non-negligible amount of events, PFSimParticleProducer crashes with the following error message

----- Begin Fatal Exception [...]-----------------------
An exception of category 'FastSim' occurred while
   [0] Processing  Event run: 1 lumi: 2757 event: 2756952 stream: 0
   [1] Running path 'pfSimParticlePath'
   [2] Calling method for module PFSimParticleProducer/'particleFlowSimParticle'
Exception Message:
Index for FSimVertex out of range, please contact FastSim developers
----- End Fatal Exception ------------------------------

This error was already reported in previous years, apparently without a clear solution:
https://indico.cern.ch/event/673246/contributions/2757878/attachments/1541980/2418599/JMEHLTX-POG.pdf
https://hypernews.cern.ch/HyperNews/CMS/get/eflow/1011/1/1.html
https://hypernews.cern.ch/HyperNews/CMS/get/famos/687.html

Some debugging [*] led to the update in this PR, which fixes the issue.

FYI: @lathomas @kirschen @hatakeyamak @bendavid @pallabidas

---

[*] More debugging information.

The crash occurs in FBaseSimEvent, and was caused by instances where

• KineParticleFilter::acceptVertex would fail (return false)
  

  cmssw/FastSimulation/Event/src/KineParticleFilter.cc

  Line 59 in 03dd22b

  bool KineParticleFilter::acceptVertex(const XYZTLorentzVector& vertex) const {

  
  and this would cause the vertex-id in
  

  cmssw/FastSimulation/Event/src/FBaseSimEvent.cc

  Line 178 in 03dd22b

  myVertices[vertexId] = addSimVertex(position, originId);

  
  to be -1
  

  cmssw/FastSimulation/Event/src/FBaseSimEvent.cc

  Line 529 in 03dd22b

  return -1;

• in the ensuing call to FBaseSimEvent::addSimTrack
  

  cmssw/FastSimulation/Event/src/FBaseSimEvent.cc

  Line 199 in 03dd22b

  myTracks[trackId] = addSimTrack(&part, myVertices[vertexId], track.genpartIndex());

  
  KineParticleFilter::acceptParticle would return true
  

  cmssw/FastSimulation/Event/src/FBaseSimEvent.cc

  Line 487 in 03dd22b

  if (!myFilter->acceptParticle(*p) && ig >= -1)

  
  because of
  

  cmssw/FastSimulation/Event/src/KineParticleFilter.cc

  Line 37 in 03dd22b

  return true;

• and, ultimately, the crash would occur here, because of iv being -1
  

  cmssw/FastSimulation/Event/src/FBaseSimEvent.cc

  Line 498 in 03dd22b

  vertex(iv).addDaughter(trackId);

In summary, it seems that, when KineParticleFilter::acceptVertex returns false, then KineParticleFilter::acceptParticle should also return false for particles associated to that vertex. When this is not the case (i.e. without the suggested fix), the logic in FBaseSimEvent starts to break.

---

PR validation:

Private tests on the affected JME workflow.

if this PR is a backport please specify the original PR and why you need to backport that PR:

N/A (no backport planned)

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33088/21411

• This PR adds an extra 12KB to repository

[cmsbuild]

A new Pull Request was created by @missirol (Marino Missiroli) for master.

It involves the following packages:

FastSimulation/Event

@ssekmen, @lveldere, @civanch, @mdhildreth, @cmsbuild, @sbein can you please review it and eventually sign? Thanks.
@matt-komm this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[civanch]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-fce5a2/13314/summary.html
COMMIT: c61b46b
CMSSW: CMSSW_11_3_X_2021-03-06-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/33088/13314/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

@slava77 comparisons for the following workflows were not done due to missing matrix map:

• /data/cmsbld/jenkins/workspace/compare-root-files-short-matrix/data/PR-fce5a2/34634.0_TTbar_14TeV+2026D76+TTbar_14TeV_TuneCP5_GenSimHLBeamSpot14+DigiTrigger+RecoGlobal+HARVESTGlobal
• /data/cmsbld/jenkins/workspace/compare-root-files-short-matrix/data/PR-fce5a2/34834.999_TTbar_14TeV+2026D76PU_PMXS1S2PR+TTbar_14TeV_TuneCP5_GenSimHLBeamSpot14+PREMIX_PremixHLBeamSpot14PU+DigiTriggerPU+RecoGlobalPU+HARVESTGlobalPU

Summary:

• No significant changes to the logs found
• Reco comparison results: 3 differences found in the comparisons
• DQMHistoTests: Total files compared: 38
• DQMHistoTests: Total histograms compared: 2849195
• DQMHistoTests: Total failures: 6
• DQMHistoTests: Total nulls: 1
• DQMHistoTests: Total successes: 2849166
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.004 KiB( 37 files compared)
• DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
• Checked 160 log files, 37 edm output root files, 38 DQM output files

[missirol]

The very few differences in the comparisons don't seem (to me) related to the update in this PR.
I was wondering if FastSim experts have any feedback on whether or not this is the correct fix for the issue at hand.

[missirol]

A kind ping for the review of this PR. This fix is needed for Run-3 JME studies.

[civanch]

@sbein, it seems the PR is fine.

[qliphy]

ping @cms-sw/fastsim-l2

[sbein]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[qliphy]

+1

[sbein]

@missirol thank you very much for tracking this down. To me the change correctly fixes the issue and as you point out fixes a long-standing problem seen in JME. What I'm trying to understand is why this did not mess anything up for normal physics - why only JME... anyways, it is accepted so thanks again.

[missirol]

Thanks @sbein , and others, for having a look.

What I'm trying to understand is why this did not mess anything up for normal physics [..]

That'd be interesting for know, in case you find more information. My rough understanding is that PFSimParticleProducer is only used in very few (non-central) workflows.

[sbein]

Thanks @sbein , and others, for having a look.

What I'm trying to understand is why this did not mess anything up for normal physics [..]

That'd be interesting for know, in case you find more information. My rough understanding is that PFSimParticleProducer is only used in very few (non-central) workflows.

ok I will keep an eye out if there are other examples. TY