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
Cache pixel cluster shape data #3211
Conversation
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_7_1_X. Cache pixel cluster shape data It involves the following packages: Configuration/StandardSequences @civanch, @Dr15Jones, @lveldere, @vlimant, @davidlange6, @ianna, @mdhildreth, @cmsbuild, @anton-a, @thspeer, @giamman, @slava77, @franzoni, @Degano, @ktf, @nclopezo can you please review it and eventually sign? Thanks. |
@Martin-Grunewald Please find below a recipe for the ConfDB migration (tested privately). Let me know if any additional steps are needed. Once migrated, shall I cherry-pick the relevant commit(s) from you, or do you want to take over the PR? (I'd prefer the former) For TrajectoryFilter and BaseCkfTrajectoryBuilder, each case is independent of others. Below I assume no change in labels in ESP->PSet for simplicity.
Adding the cache producer and InputTag We need one instance of SiPixelClusterShapeCacheProduce for each SiPixelClusterProducer. Currently, only some instances of PixelTrackProducer use the pixel cluster shape data. Below is a recipe on how to find the proper SiPixelClusterProducer given a PixelTrackProducer configuration.
|
Note that before the ConfDB has been migrated and the dumps updated, all workflows running HLT will fail. Therefore it is probably not worthwhile to run the tests yet. |
@@ -0,0 +1,114 @@ | |||
#ifndef FWCore_Utilities_VecArray_h |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also considered DataFormats/Common package for this template, but ended up putting it here.
Hi Matti, Ah, now it is materialised. I'll make a branch from which you can add / cherry pick the HLT stuff. |
Hi Martin, Ok, thanks! |
@@ -1,6 +1,6 @@ | |||
import FWCore.ParameterSet.Config as cms | |||
|
|||
from RecoTracker.TransientTrackingRecHit.TransientTrackingRecHitBuilderWithoutRefit_cfi import * | |||
from RecoMuon.L3TrackFinder.MuonCkfTrajectoryBuilderESProducer_cff import * | |||
from RecoMuon.L3TrackFinder.MuonCkfTrajectoryBuilder_cff import * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FastSim seems to be the only thing that is importing from RecoMuon.L3TrackFinder.MuonCkfTrajectoryBuilder_cff
Can you confirm that the changes in that cfg file have no impact on physics?
Thanks
Lukas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't test FastSim (shame on me), but based on grepping muonCkfTrajectoryBuilder
appears only in https://github.com/cms-sw/cmssw/blob/CMSSW_7_1_X/FastSimulation/Muons/python/L3Muons_cfi.py#L19, where a FastL3MuonProducer
EDProducer is configured. However,
- the producer is configured only if a flag
old==True
, which isFalse
by default in the configuration file, and FastL3MuonProducer
doesn't seem to exist anymore (nothing to migrate from ESProduct to helper plugin in here).
At the time I concluded that this piece of L3Muons_cfi.py would be obsolete, but didn't see the larger picture until now (i.e. if the "old" piece can indeed be removed, so could the import you noted).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for my late reaction, I never received your reply in my inbox.
ok, I'll add this to my list of dead FastSim code.
I'll +1, under the condition that no FastSim regression is observed in the comparison test.
A small update based on private discussion with @VinInn, @cerati, and @rovere:
|
+1 under condition that no regression is observed in comparison test |
+1 |
Hi Matti, I have a problem with this part - the updates of the EDProducers: process.name = cms.EDProducer("CkfTrackCandidateMaker", process.name = cms.EDProducer("CkfTrajectoryMaker", Could you keep in the above the old TrajectoryBuilder as (then unused) string parameter Thanks a lot Martin |
Deeming operations signature not needed. Reason why it is affected is the fact that Configuration/StandardSequences/python/Reconstruction_cff.py now has siPixelClusterShapeCache, which reco is ok with. |
Reco -- Cache pixel cluster shape data
Now that this got merged, I'll follow up on the cleanup of the now-obsolete ESProducer configurations, and on the MuonRoadTrajectoryBuilder. |
Oh, and I almost forgot, could Slava (or somebody else) comment if something should be done on the configuration files listed in #3211 (comment)? In principle I think they should be either fixed or removed as obsolete (but in practice leaving them as is could be an option too). |
again, are v. On 15 Apr, 2014, at 9:04 AM, Matti Kortelainen notifications@github.com wrote:
|
looks like they are not used... I would rm and see what happens... |
Including the corresponding Seed Producer? |
no the seed producer is run via this: sorry I though the problem was with the cff's and not with the producer itself |
As far as I'm concerned, the problem is in the cff's (mainly it is annoying to migrate potentially obsolete files). |
Reco -- Post-#3211 cleanup (MuonRoadTrajectoryBuilder, configuration files)
This PR adds caching of pixel cluster shape data. As a prerequisite, in order to allow
ClusterShapeTrajectoryFilter
to read data product from Event, theBaseCkfTrajectoryBuilder
andTrajectoryFilter
derived classes are transformed from ESProducts to helper plugins.The cache can be filled also on demand (
onDemand
parameter ofSiPixelClusterShapeProducer
). This mode might be interesting for HLT, at least in my tests there was improvement in timing. The downside is the need of some sort of synchronization, now done withedm::SerialTaskQueue
(not sure if this is the best approach). I think any solution used for on-demandedmNew::DetSetVector<>
should also work here.The configuration migration relies on the newly added
refToPSet_
feature (#3072, #3146). The configuration files for the removed ESProducers are still kept for ConfDB migration.This PR removes
BaseCkfTrajectoryBuilder
andClusterShapeTrajectoryFilter
from the list of thread-unsafe ESProducts.BaseCkfTrajectoryBuilder::createStartingTrajectory() const
does still modify mutable members, but as theBaseCkfTrajectoryBuilder
objects are local to each EDModule, the class should in practice be thread-friendly at Event level.This PR includes also various cleanups (mainly removal of edm::ParameterSet members) on
Future work to be done after this PR gets merged
MuonRoadTrajectoryBuilder
from ESProduct to helper plugin (?)BaseCkfTrajectoryBuilder
(done in 69fddd4 in this PR)References
Rebased and tested on CMSSW_7_1_X_2014-04-02-1400, should not change physics results.