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

Seeding layers ESP to EDP migration #2378

Merged
merged 50 commits into from
Feb 19, 2014

Conversation

Martin-Grunewald
Copy link
Contributor

Seeding layers ESP to EDP migration

Includes and superseeds for 71X both #2286 and #2308.

…s unused

This simplifies further development of SeedingLayerSetsBuilder.
…nterface

The old interface needs to be kept, because some classes use it with
ctfseeding:SeedingLayer's constructed without SeedingLayersESProducer.
I used templates in CosmicTrackingRegion and
RectangularEtaPhiTrackingRegion to avoid copy-pasting.
In QuadrupletSeedMerger SeedingLayerSets are used only to iterate over
layer-quadruplets. Therefore SeedingLayersEDProducer would mean
unnecessary work by creating the TTRHs. Therefore I decided to just
deliver the SeedingLayerSetsBuilder PSet to QuadrupletSeedMerger, and
construct SeedingLayerSetsBuilder in the constructor.
Will need to deliver edm::ConsumesCollector to OrderedHitsGenerator in
SeedFilter (to be added in a later commit).

As a knock-on effect, move SeedFilter construction from beginRun() to
constructor in ElectronSeedProducer. Also, use std::unique_ptr for
SeedFilter.
Will be needed to deliver edm::ConsumesCollector to
- CombinedHitPairGenerator
- CombinedMultiHitGenerator
- CombinedHitTripletGenerator
- CombinedHitPairGeneratorForPhotonConversion
- CombinedHitQuadrupletGeneratorForPhotonConversion

Following concrete classes inherit from OrderedHitsGenerator
- BeamHaloPairGenerator
- GenericPairGenerator
- GenericTripletGenerator
- CombinedHitPairGenerator
- CombinedMultiHitGenerator
- CombinedHitTripletGenerator
- CombinedHitPairGeneratorForPhotonConversion
- CombinedHitQuadrupletGeneratorForPhotonConversion

Knock-on effects:

Pass ConsumesCollector to OrderedHitsFactory
- TSGSmart

+ move construction of OrderedHitsGenerator to constructor
- TSGFromL1Muon (from beginRun)
- PixelTrackReconstruction (from beginRun)
- HitTripletProducer (from init)
- CtfSpecialSeedGenerator (from beginRun)
- PhotonConversionTrajectorySeedProducerFromSingleLegAlgo (from init)
- ConversionSeedGenerators/src/PhotonConversionTrajectorySeedProducerFromQuadrupletsAlgo (from init)

+ move construction of SeedGeneratorFromRegionHits to constructor
- TSGFromOrderedHits
- EgammaHLTRegionalPixelSeedGeneratorProducers

+ move construction of SeedComparitor and SeedCreator to constructor
- SeedGeneratorFromRegionHitsEDProducer
Needed for edm::ConsumesCollector (in later commit).
@Martin-Grunewald
Copy link
Contributor Author

Could AlCa please sign this PR so that it gets integrated? It is now one week....

@cerati
Copy link
Contributor

cerati commented Feb 17, 2014

I second the request of integrating this PR asap (it touches the whole tracking code and makes difficult for developers to avoid conflicts)

@rcastello
Copy link

+1
AlCa signed. sorry for the delay

@ktf
Copy link
Contributor

ktf commented Feb 19, 2014

RecoTracker/SeedingLayerSetsHits is a new package. Adding it to reco. Complain if not ok.

ktf added a commit that referenced this pull request Feb 19, 2014
Reco updates -- Seeding layers ESP to EDP migration
@ktf ktf merged commit 43c72bc into cms-sw:CMSSW_7_1_X Feb 19, 2014
@davidlange6
Copy link
Contributor

hum, maybe we don't need a new package for one class?

On Feb 19, 2014, at 9:00 AM, Giulio Eulisse notifications@github.com
wrote:

RecoTracker/SeedingLayerSetsHits is a new package. Adding it to reco. Complain if not ok.


Reply to this email directly or view it on GitHub.

@makortel
Copy link
Contributor

The "one class" in the new package is a transient-only EDProduct depending on TransientTrackingRecHit. Given the restrictions in https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideCreatingNewProducts it was easiest to prototype in a new package. I'm of course happy to move the class to an existing package if there are better suggestions.

(maybe we should have had this discussion before merging? :)

@davidlange6
Copy link
Contributor

Thanks for the explanation Matti. maybe its best to move it together with TransientTrackingRecHit if that is what it depends on?

On Feb 19, 2014, at 10:00 AM, Matti Kortelainen notifications@github.com
wrote:

The "one class" in the new package is a transient-only EDProduct depending on TransientTrackingRecHit. Given the restrictions in https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideCreatingNewProducts it was easiest to prototype in a new package. I'm of course happy to move the class to an existing package if there are better suggestions.

(maybe we should have had this discussion before merging? :)


Reply to this email directly or view it on GitHub.

@Martin-Grunewald
Copy link
Contributor Author

Hi,

Please do NOT unmerge. Make a new PR with only this change.
Otherwise we'll have to wait another week before all signatures are in.

Thanks and best regards

Martin

On Wed, 19 Feb 2014, davidlange6 wrote:

Thanks for the explanation Matti. maybe its best to move it together with TransientTrackingRecHit if that is what it depends on?

On Feb 19, 2014, at 10:00 AM, Matti Kortelainen notifications@github.com
wrote:

The "one class" in the new package is a transient-only EDProduct depending on TransientTrackingRecHit. Given the restrictions in https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideCreatingNewProducts it was easiest to prototype in a new package. I'm of course happy to move the class to an existing package if there are better suggestions.

(maybe we should have had this discussion before merging? :)


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub:
#2378 (comment)

Martin

Martin W. Gruenewald e-mail: Martin.Grunewald@cern.ch
http://cern.ch/Martin.Grunewald

@makortel
Copy link
Contributor

@davidlange6 Fine for me. I first though that SeedingLayerSetsHits class would not have that much to do with TransientTrackingRecHit (except of using it), but it could be though as a very specialized container of TransientTrackingRecHits. The only new package dependence to TrackingTools/TransientTrackingRecHit would be FWCore/MessageLogger, which I guess is fine.

@Martin-Grunewald I fully agree. At this stage a new PR with just the move would probably be easiest for everybody.

I'll start preparing a new PR to move the class to TrackingTools/TransientTrackingRecHit, so please scream if there are other opinions.

@ktf
Copy link
Contributor

ktf commented Feb 19, 2014

Indeed this was merged since everyone has to sign about this. With git we can easily drop packages.

@davidlange6
Copy link
Contributor

Matti, is there a big change in the number of packages that would now depend on the ttrh package?

On Feb 19, 2014, at 10:16 AM, "Matti Kortelainen" <notifications@github.commailto:notifications@github.com> wrote:

@davidlange6https://github.com/davidlange6 Fine for me. I first though that SeedingLayerSetsHits class would not have that much to do with TransientTrackingRecHit (except of using it), but it could be though as a very specialized container of TransientTrackingRecHits. The only new package dependence to TrackingTools/TransientTrackingRecHit would be FWCore/MessageLogger, which I guess is fine.

@Martin-Grunewaldhttps://github.com/Martin-Grunewald I fully agree. At this stage a new PR with just the move would probably be easiest for everybody.

I'll start preparing a new PR to move the class to TrackingTools/TransientTrackingRecHit, so please scream if there are other opinions.


Reply to this email directly or view it on GitHubhttps://github.com//pull/2378#issuecomment-35479294.

@makortel
Copy link
Contributor

David, do you mean through the dependence on SeedingLayerSetsHits? There should be no new packages depending on TTRH, because all packages now using SeedingLayerSetsHits used/depended on TTRH (directly or via some other package) already prior to #2378.

@davidlange6
Copy link
Contributor

Yes, that's what I meant. It seems then this package is indeed a good spot.

On Feb 19, 2014, at 10:51 AM, "Matti Kortelainen" <notifications@github.commailto:notifications@github.com> wrote:

David, do you mean through the dependence on SeedingLayerSetsHits? There should be no new packages depending on TTRH, because all packages now using SeedingLayerSetsHits used/depended on TTRH (directly or via some other package) already prior to #2378#2378.


Reply to this email directly or view it on GitHubhttps://github.com//pull/2378#issuecomment-35481925.

@makortel
Copy link
Contributor

Moved SeedingLayerSetsHits to TrackingTools/TransientTrackingRecHit package in PR #2527.

@nclopezo nclopezo modified the milestones: CMSSW_7_1_0_pre4, CMSSW_7_1_0_pre3 Feb 24, 2014
This was referenced Mar 5, 2014
@nclopezo nclopezo modified the milestones: CMSSW_7_1_0_pre5, CMSSW_7_1_0_pre4 Mar 10, 2014
@Martin-Grunewald Martin-Grunewald deleted the SeedingLayers branch April 1, 2014 05:12
shervin86 pushed a commit to shervin86/cmssw that referenced this pull request May 11, 2015
Reco updates -- Seeding layers ESP to EDP migration
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.