Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not update HepMCProduct in place (producer implementation) #10858

Merged
merged 1 commit into from
Sep 25, 2015

Conversation

wmtan
Copy link
Contributor

@wmtan wmtan commented Aug 19, 2015

This PR is the chosen implementation for avoiding modifying HepMCProduct in place (aka smearing the vertices in place). The smearers (aka vertex generators) still run as EDProducers, but they copy the HepMCProduct, smear the copy, and put the copy into the event with module label "VtxSmeared".
In order to make this PR backward compatible (see below) another producer with label "generatorSmeared"copies the HepMCProduct, and the HepMCProduct with label "generatorSmeared" is the one that is kept on output.
The consumers of the smeared HepMCProduct are modified to use the module label "generatorSmeared" instead of "generator". Also, the generators now create the HepMCProduct with the product instance name "unsmeared", so consumers of the unsmeared HepMCProduct must explicitly use "unsmeared" as the product instance name, in addition to the "generator" module label. This is a defensive measure to ensure that consumers always get the smeared HepMCProduct unless they explicitly specify "unsmeared".
For backward compatibility, the producer of HepMCProduct with label "generatorSmeared" also runs at the beginning of the digitization step. If it finds a HepMCproduct with label "generator" or "VtxSmeared", it copies it, creating a HepMCProduct with module label "generatorSmeared". In this way, files containing GEN-SIM written prior to this PR can still be read.

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @wmtan for CMSSW_7_6_X.

Do not update HepMCProduct in place (producer implementation)

It involves the following packages:

Alignment/LaserAlignmentSimulation
Calibration/HcalCalibAlgos
Calibration/IsolatedParticles
Configuration/EcalTB
Configuration/Generator
Configuration/StandardSequences
DPGAnalysis/SiStripTools
EgammaAnalysis/ElectronTools
ElectroWeakAnalysis/ZMuMu
FastSimulation/Configuration
FastSimulation/EventProducer
FastSimulation/ForwardDetectors
GeneratorInterface/AMPTInterface
GeneratorInterface/AlpgenInterface
GeneratorInterface/BeamHaloGenerator
GeneratorInterface/Configuration
GeneratorInterface/Core
GeneratorInterface/CosmicMuonGenerator
GeneratorInterface/ExternalDecays
GeneratorInterface/GenFilters
GeneratorInterface/Herwig6Interface
GeneratorInterface/HiGenCommon
GeneratorInterface/Hydjet2Interface
GeneratorInterface/HydjetInterface
GeneratorInterface/LHEInterface
GeneratorInterface/MCatNLOInterface
GeneratorInterface/PyquenInterface
GeneratorInterface/Pythia6Interface
GeneratorInterface/Pythia8Interface
GeneratorInterface/RivetInterface
GeneratorInterface/TauolaInterface
IOMC/EventVertexGenerators
IOMC/Input
IOMC/ParticleGuns
PhysicsTools/HepMCCandAlgos
PhysicsTools/PatAlgos
RecoEcal/EgammaCoreTools
RecoEgamma/Examples
RecoJets/JetAnalyzers
RecoParticleFlow/Configuration
RecoParticleFlow/PFProducer
SUSYBSMAnalysis/HSCP
SimCalorimetry/EcalTestBeam
SimDataFormats/GeneratorProducts
SimG4CMS/Calo
SimG4Core/Application
SimGeneral/MixingModule
SimGeneral/PileupInformation
SimGeneral/TrackingAnalysis
SimMuon/GEMDigitizer
SimMuon/RPCDigitizer
SimTracker/TrackHistory
SimTracker/TrackerMaterialAnalysis
SimTransport/HectorProducer
TauAnalysis/MCEmbeddingTools
Validation/CaloTowers
Validation/Configuration
Validation/EcalClusters
Validation/EcalDigis
Validation/EcalHits
Validation/EcalRecHits
Validation/EventGenerator
Validation/HcalHits
Validation/HcalRecHits
Validation/RecoEgamma
Validation/RecoHI
Validation/RecoJets
Validation/RecoParticleFlow
Validation/RecoVertex

@diguida, @lveldere, @cerminar, @covarell, @bendavid, @civanch, @cmsbuild, @davidlange6, @vciulli, @smuzaffar, @Dr15Jones, @cvuosalo, @mdhildreth, @deguio, @slava77, @vadler, @mmusich, @ssekmen, @danduggan, @thuer, @monttj, @franzoni can you please review it and eventually sign? Thanks.
@ghellwig, @TaiSakuma, @abbiendi, @rappoccio, @argiro, @Martin-Grunewald, @istaslis, @lgray, @threus, @venturia, @mmarionncern, @battibass, @makortel, @acaudron, @jhgoh, @dgulhan, @inugent, @jdolen, @ferencek, @cerati, @trocino, @Sam-Harper, @kkrajczar, @GiacomoSguazzoni, @rovere, @VinInn, @nhanvtran, @schoef, @mschrode, @richard-cms, @mkirsano, @imarches, @ahinzmann, @rylanC24, @gpetruc, @matt-komm, @mariadalfonso, @pvmulder, @cbaus, @bachtis this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

@slava77
Copy link
Contributor

slava77 commented Aug 19, 2015

@cmsbuild please test

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

-1

Tested at: 7a4f54f
I found errors in the following unit tests:

---> test runtestPhysicsToolsPatAlgos had ERRORS

you can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10858/7474/summary.html

@wmtan
Copy link
Contributor Author

wmtan commented Aug 19, 2015

@cmsbuild @davidlange6 the unit test that fails also fails in the base IB. The failure is not caused by this PR.

@cmsbuild
Copy link
Contributor

@lveldere
Copy link
Contributor

+1

fastsim edits look ok,
differences observed in fastsim comparisons,
look compatible with fullsim comparisons.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@wmtan
Copy link
Contributor Author

wmtan commented Sep 22, 2015

@covarell, @bendavid, @govoni, @vciulli, @cvuosalo, @slava77, @vadler, @thuer, @monttj, @franzoni ping: analysis, generators, operations, reconstruction Can you either sign this, or provide a reason for not signing.

class HepMCProduct;
}

class GeneratorSmearedProducer : public edm::EDProducer {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this one not thread-aware? (edm::one, stream )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this new producer, as well as the modified vertex smeared producer, should be thread aware (e.g. one, stream, or global), just as all other modules should be. That should happen in due course.

@slava77
Copy link
Contributor

slava77 commented Sep 23, 2015

+1

for #10858 f719245

  • code changes are mostly as expected
  • a newly introduced producer class GeneratorSmearedProducer : public edm::EDProducer should be changed to an edm::one, I suppose, but better do it in a separate PR to have less signatures to collect
  • jenkins tests pass and comparisons with the baseline show no differences

@wmtan
Copy link
Contributor Author

wmtan commented Sep 24, 2015

@covarell, @bendavid, @govoni, @vciulli, @vadler, @thuer, @monttj, @franzoni
ping again: analysis, generators, operations Can you either sign this, or provide a reason for not signing?

davidlange6 added a commit that referenced this pull request Sep 25, 2015
Do not update HepMCProduct in place (producer implementation)
@davidlange6 davidlange6 merged commit 46011a7 into cms-sw:CMSSW_7_6_X Sep 25, 2015
@wmtan wmtan deleted the VtxSmeared branch October 6, 2015 17:14
@ferencek
Copy link
Contributor

ferencek commented Oct 8, 2015

@wmtan, this PR has broken the jet flavor code. In CMSSW_7_6_X_2015-10-07-2300 I now get a bunch of warnings like the following one

Begin processing the 500th record. Run 1, Event 1800, LumiSection 18 at 08-Oct-2015 00:32:46.939 CDT
%MSG-w UndefinedPartonMode:  HadronAndPartonSelector:patJetPartons  08-Oct-2015 00:32:46 CDT Run: 1 Event: 1800
Could not automatically determine the hadronizer type and set the correct parton selection mode. Parton-based jet flavour will not be defined.

when running PAT tests. How did this go unnoticed?

Anyways, the hadron and parton selector defined in PhysicsTools/JetMCAlgos/plugins/HadronAndPartonSelector.cc needs to access the GenEventInfoProduct in order to determine the hadronizer type. What is the proposed solution here. Is that product still available in the event and under what name?

@wmtan
Copy link
Contributor Author

wmtan commented Oct 8, 2015

@ferencek This PR should not have affected the GenEventInfoProduct in any way.
Please provide evidence that this PR broke the jet flavor code.
At a minimum, I would need a cmsRun job that reproduces this error.
I cannot provide a solution to a problem that I do not understand, and that, at least on the surface, appears to have nothing whatever to do with this PR.

@ferencek
Copy link
Contributor

ferencek commented Oct 8, 2015

@wmtan, evidence is the printout I provided above. The problem can be reproduced by runnning pretty much any of the PAT unit tests. For instance, running PhysicsTools/PatAlgos/test/patTuple_standard_cfg.py should suffice.

The problem originates from the change made in PhysicsTools/PatAlgos/python/mcMatchLayer0/jetFlavourId_cff.py. If the GenEventInfoProduct is unaffected, then changing

src = cms.InputTag("generatorSmeared"),

back to

src = cms.InputTag("generator"),

should fix the issue.

@wmtan
Copy link
Contributor Author

wmtan commented Oct 8, 2015

@ferencek 1) The reason this problem was not found is that it does not cause any tests to fail. The PR approval process does not scan all output files for new warning messages.
2) I now understand the problem. It is only a backward compatibility issue. GenEventInfoProduct is indeed unaffected. Changing "generatorSmeared" back to "generator" does indeed fix the unit test, but only because the file being read predates this PR. Once a new input file for this test is generated, it would have to be changed back to "generatorSmeared".
3) Backward compatibility was indeed addressed in this PR, but the fix does not cover the unusual workflow in this test.
4) Further discussion should be in e-mail outside of github, unless it is very short. If you want a record of the further discussion, use an appropriate HN forum.

@ferencek
Copy link
Contributor

ferencek commented Oct 8, 2015

@wmtan, ok, it sounds like the problem will be fixed once the input RelVals are updated to a version that contains this PR. In that case, I don't think any fixes are needed.

@wmtan
Copy link
Contributor Author

wmtan commented Oct 8, 2015

@ferencek That is correct, assuming that the relvals in question smear the vertices in HepMCProduct, which they should.

@ferencek
Copy link
Contributor

@wmtan, I had a look at one of the files from /RelValProdTTbar_13/CMSSW_7_6_0_pre7-76X_mcRun2_asymptotic_v5-v1/AODSIM and here is what I see

[ferencek@cmslpc25 src]$ edmDumpEventContent root://cmsxrootd-site.fnal.gov//store/relval/CMSSW_7_6_0_pre7/RelValProdTTbar_13/AODSIM/76X_mcRun2_asymptotic_v5-v1/00000/0E9A5DE8-1D71-E511-A205-00261894380D.root
Type                                  Module                      Label             Process   
----------------------------------------------------------------------------------------------
GenEventInfoProduct                   "generator"                 ""                "SIM"     
edm::TriggerResults                   "TriggerResults"            ""                "SIM"     
edm::TriggerResults                   "TriggerResults"            ""                "HLT"     
int                                   "addPileupInfo"             "bunchSpacing"    "HLT"     
vector<PileupSummaryInfo>             "addPileupInfo"             ""                "HLT"     
vector<int>                           "genParticles"              ""                "HLT"
...

and

[ferencek@cmslpc25 src]$ edmProvDump  root://cmsxrootd-site.fnal.gov//store/relval/CMSSW_7_6_0_pre7/RelValProdTTbar_13/AODSIM/76X_mcRun2_asymptotic_v5-v1/00000/0E9A5DE8-1D71-E511-A205-00261894380D.root | grep -i cmssw
  SIM '' '"CMSSW_7_6_0_pre7"' (6459b08dbcc3c6e5421bfc57cfa6cb04)
    HLT '' '"CMSSW_7_6_0_pre7"' (e355911c26dddb8d43fe6d5bca5bbf21)
      RECO '' '"CMSSW_7_6_0_pre7"' (39f973222d399b2f7e7caed12b632381)
  EfficiencyMap: string tracked  = 'CondFormats/JetMETObjects/data/CMSSW_538_TrackNonEff.txt'
  LeakageMap: string tracked  = 'CondFormats/JetMETObjects/data/CMSSW_538_TrackLeakage.txt'
  ResponseMap: string tracked  = 'CondFormats/JetMETObjects/data/CMSSW_538_response.txt'
  tagName: vstring tracked  = {'ZSP_CMSSW390_Akt_05_PU0'}
   FileName: FileInPath tracked  = V001 SimG4CMS/Forward/data/CastorShowerLibrary_CMSSW500_Standard.root 2 /external/slc6_amd64_gcc493/data/SimG4CMS/Forward/data/CastorShowerLibrary_CMSSW500_Standard.root

and I don't see any GenEventInfoProducts called "generatorSmeared". I'm not sure if that was expected but if so, then the changes made in PhysicsTools/PatAlgos/python/mcMatchLayer0/jetFlavourId_cff.py should be reverted.

@wmtan
Copy link
Contributor Author

wmtan commented Oct 23, 2015

@ferencek The label "generatorSmeared" only applies to HepMCProduct, not to GenEventInfoProduct.
So, nothing is wrong here.

@ferencek
Copy link
Contributor

@wmtan, thanks for the reply. Then my comment stands. The change done in PhysicsTools/PatAlgos/python/mcMatchLayer0/jetFlavourId_cff.py should be reverted since the modified parameter does not refer to a HepMCProduct but a GenEventInfoProduct. I can make a PR for that if you agree that this is what should be done. Thanks

@wmtan
Copy link
Contributor Author

wmtan commented Oct 23, 2015

@ferencek Yes, you are right. It does refer to a GenEventInfoProduct. The change to that one file should be reverted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment