Event based track and muon to simulation associators #7175
Conversation
Previously, TrackAssociatorByChi2 would also match a generated particle to a track. In order to use it code would get it from the EventSetup via its base class and then cast it to its actual type. By creating a seperate TrackGenAssociatorBase and TrackGenAssociatorByChi2 it avoids the use of casting. This is a step towards fixing the consumes problem with TrackAssociators.
Previously, code was getting a TrackAssociatorBase from the EventSetup and casting it to a MuonAssociatorByHits in order to do muon association. This change creates a separate MuonToSimAssociatorBase which provides the correct interface. This new object can be obtained from the EventSetup and is created by MuonAssociatorESProducer. Common code was moved to MuonAssociatorByHitsHelper. This change is needed as a step towards fixing the consumes problem with TrackAssociatorBase.
Made the routines used by MuonAssociatorByHitsHelper const.
The MuonAssociatorByHitsHelper was only using a small portion of MuonTruth and no other user of MuonTruth used that portion. Splitting the functionality to its own class helps reduce dependencies and avoids unnecessary time and memory.
Classes which use MuonAssociatorByHitsHelper are now responsible for passing it the Event and EventSetup based resources it needs.
The various Reco to Sim assocation implementations require each implementation to use additional information from the Event and/or EventSetup. Inorder to accommodate that and to get the 'consumes' to work, the association classes need to be Event data products. This change provides the event data product for the three types of associations and the base class for the actual implementations of the associations. Classes which inherit from the base class are defined in additional pacakges. This works since the associations are transient only.
The implementations of the associations are all copies of the code in SimTrack/TrackAssociation where the Event or EventSetup data products are held by the product rather than obtained from the Event or EventSetup each call. These implement the interface defined in SimDataFormats/Associations.
The implementations of the associations are all copies of the EventSetup based product code where the Event or EventSetup data products are held by the product rather than obtained from the Event or EventSetup each call. This implement the interface defined in SimDataFormats/Associations.
…rBase The TrackAssociatorBase lives in the EventSetup but gets data from both the edm::Event and edm::EventSetup. This is not allowed by CMSSW rules. Therefore TrackAssociatorBase is replaced by reco::TrackToTrackingParticleAssociator which is obtained via the edm::Event. This solves the consumes problem associated with TrackAssociatorBase usage.
TrackGenAssociatorBase is an EventSetup object which uses the edm::Event to get data. This is a problem for consumes. So instead we nw use the reco::TrackToGenParticleAssociator which does the same work but is an edm::Event product which already contains the data it needs from the event.
…atorBase MuonToSimAssociatorBase is an EventSetup object which uses the edm::Event to get data. This is a problem for consumes. So instead we nw use the reco::MuonToTrackingParticleAssociator which does the same work but is an edm::Event product which already contains the data it needs from the event.
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for CMSSW_7_4_X. Event based track and muon to simulation associators It involves the following packages: Alignment/OfflineValidation The following packages do not have a category, yet: SimDataFormats/Associations @civanch, @diguida, @lveldere, @cvuosalo, @ianna, @mdhildreth, @monttj, @cmsbuild, @cerminar, @franzoni, @Dr15Jones, @rcastello, @deguio, @slava77, @danduggan, @vadler, @mmusich, @davidlange6, @ktf, @nclopezo can you please review it and eventually sign? Thanks. |
|
please test |
|
The tests are being triggered in jenkins. |
|
-1 Copying tmp/slc6_amd64_gcc491/src/SimMuon/MCTruth/src/SimMuonMCTruth/libSimMuonMCTruth.so to productstore area:
Leaving library rule at SimMuon/MCTruth
>> Compiling /build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/Validation/RecoTrack/src/MTVHistoProducerAlgoFactory.cc
>> Compiling /build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/Validation/RecoTrack/src/MTVHistoProducerAlgoForTracker.cc
/build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/Validation/RecoB/plugins/recoBSVTagInfoValidationAnalyzer.cc: In constructor 'recoBSVTagInfoValidationAnalyzer::recoBSVTagInfoValidationAnalyzer(const edm::ParameterSet&)':
/build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/Validation/RecoB/plugins/recoBSVTagInfoValidationAnalyzer.cc:95:121: error: no matching function for call to 'VertexClassifierByProxystd::vector, reco::JTATagInfo>, reco::Vertex> > >::VertexClassifierByProxy(const edm::ParameterSet&)'
recoBSVTagInfoValidationAnalyzer::recoBSVTagInfoValidationAnalyzer(const edm::ParameterSet& config) : classifier_(config)
^
/build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/Validation/RecoB/plugins/recoBSVTagInfoValidationAnalyzer.cc:95:121: note: candidates are:
In file included from /build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/Validation/RecoB/plugins/recoBSVTagInfoValidationAnalyzer.cc:21:0:
/build/cmsbuild/jenkins-workarea/workspace/ib-any-integration/CMSSW_7_4_X_2015-01-14-1400/src/SimTracker/TrackHistory/interface/VertexClassifierByProxy.h:20:5: note: VertexClassifierByProxy::VertexClassifierByProxy(const edm::ParameterSet&, edm::ConsumesCollector&&) [with Collection = std::vectorreco::TemplatedSecondaryVertexTagInfo, reco::JTATagInfo>, reco::Vertex> >]
you can see the results of the tests here: |
cmsbuild
added
alca-pending
analysis-pending
comparison-available
dqm-approved
fastsim-approved
geometry-approved
new-package-pending
operations-pending
pending-signatures
reconstruction-approved
simulation-approved
tests-approved
and removed
geometry-approved
new-package-pending
operations-pending
pending-signatures
reconstruction-approved
simulation-pending
tests-approved
labels
|
bypassing the remaining signatures on this one given the lack of complaints (so that it doesn't get out of sync and create more work) |
Event based track and muon to simulation associators
|
Apparently this one breaks one test in the gcc481 build due to some unused variable. @Dr15Jones can you have a look? |
|
gcc4.8.1 compile problem fixed in #7340 |
|
Dear all, It seems that this PR broke the HI RelVals. The related error message In Thursday's IB (CMSSW_7_4_X_2015-01-22-0200) the following cmsDriver cmsDriver.py step3 --conditions auto:run2_mc_HIon -s However, the same command in Friday's IB (CMSSW_7_4_X_2015-01-23-0200) We don't really understand the reason of the error, but we prepared a (@yetkinyilmaz and @BetterWang probably want to follow this) |
|
While investigating something unrelated within the track-TP associations, I noticed that we have still the old ESProduct-based implementations in |
Replaced TrackAssociatorBase class with three classes which are obtained from the Event. This allows
modules to properly register their 'consumes'.
This change should give identical results to the previous implementation.