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
Cleanup of Cellular Automaton seeding code #20177
Conversation
This means also removal of support for old-style seeding framework, but I'm not sure that interface would have worked anyway nowadays because of earlier changes.
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages: RecoPixelVertexing/PixelTriplets @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
The tests are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/PR-20177/133 Code check has found code style and quality issues which could be resolved by applying a patch in https://cmssdt.cern.ch/SDT/code-checks/PR-20177/133/git-diff.patch In future, you can run |
What is the logic to select the files to be given to the code style checker? |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Maybe the files modified by the PR?
On Tue, Aug 15, 2017, 17:01 Matti Kortelainen ***@***.***> wrote:
What is the logic to select the files to be given to the code style
checker?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20177 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABHaR9uixniQJx1yKgZE6PVBMZxUhFHRks5sYbJ5gaJpZM4O3r_6>
.
--
Ciao,
--Marco.
…___________
Marco Rovere
Marco.Rovere@cern.ch
CERN EP-CMG-CO | room 40 3-A28 | tel +41227671209 (71209)
|
Comparison is ready Comparison Summary:
|
I think I got the logic now. I got confused because the suggested patch What I don't understand though is how |
CAHitQuadrupletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector&& iC, bool needSeedingLayerSetsHits=true): CAHitQuadrupletGenerator(cfg, iC, needSeedingLayerSetsHits) {} | ||
CAHitQuadrupletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector& iC, bool needSeedingLayerSetsHits=true); | ||
CAHitQuadrupletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector&& iC): CAHitQuadrupletGenerator(cfg, iC) {} | ||
CAHitQuadrupletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector& iC); | ||
|
||
virtual ~CAHitQuadrupletGenerator(); |
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.
is virtual
still needed here?
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 suppose is in https://cmssdt.cern.ch/SDT/code-checks/PR-20177/133/git-diff.patch
that in my understanding has not been applied yet...
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.
To be more clear: CAHitQuadrupletGenerator does not derive from anything anymore and there is no derived class from it either. Why do we need a virtual destructor in this case?
CAHitTripletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector&& iC, bool needSeedingLayerSetsHits=true): CAHitTripletGenerator(cfg, iC, needSeedingLayerSetsHits) {} | ||
CAHitTripletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector& iC, bool needSeedingLayerSetsHits=true); | ||
CAHitTripletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector&& iC): CAHitTripletGenerator(cfg, iC) {} | ||
CAHitTripletGenerator(const edm::ParameterSet& cfg, edm::ConsumesCollector& iC); | ||
|
||
virtual ~CAHitTripletGenerator(); |
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.
is virtual
still needed?
Thanks Slava, the virtual destructor is certainly not needed (slipped through my eyes). I'll remove it early next weeknor so.
…On 21 August 2017 16:42:54 CEST, Slava Krutelyov ***@***.***> wrote:
slava77 commented on this pull request.
> @@ -38,8 +37,8 @@ class CAHitQuadrupletGenerator : public
HitQuadrupletGenerator {
public:
- CAHitQuadrupletGenerator(const edm::ParameterSet& cfg,
edm::ConsumesCollector&& iC, bool needSeedingLayerSetsHits=true):
CAHitQuadrupletGenerator(cfg, iC, needSeedingLayerSetsHits) {}
- CAHitQuadrupletGenerator(const edm::ParameterSet& cfg,
edm::ConsumesCollector& iC, bool needSeedingLayerSetsHits=true);
+ CAHitQuadrupletGenerator(const edm::ParameterSet& cfg,
edm::ConsumesCollector&& iC): CAHitQuadrupletGenerator(cfg, iC) {}
+ CAHitQuadrupletGenerator(const edm::ParameterSet& cfg,
edm::ConsumesCollector& iC);
virtual ~CAHitQuadrupletGenerator();
To be more clear: CAHitQuadrupletGenerator does not derive from
anything anymore and there is no derived class from it either. Why do
we need a virtual destructor in this case?
|
@@ -54,18 +54,11 @@ caPhiCut(cfg.getParameter<double>("CAPhiCut")), | |||
caHardPtCut(cfg.getParameter<double>("CAHardPtCut")), | |||
caOnlyOneLastHitPerLayerFilter(cfg.getParameter<bool>("CAOnlyOneLastHitPerLayerFilter")) |
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.
hi @makortel , could you also get rid of the caOnlyOneLastHitPerLayerFilter
variable in this PR?
The code-checks are being triggered in jenkins. |
@cmsbuild, please test
|
The tests are being triggered in jenkins. |
+code-checks |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
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. @davidlange6, @slava77, @smuzaffar (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
This PR cleans up unused pieces of the CA hit triplet/quadruplet finding code (the duplication of code between triplet and quadruplet is still left there as we'll try to unify them to a more generic ntuplet finder). Essentially this means the support towards the "old seeding framework", simplifying the code to serve a clearer basis for further development.
Tested in 9_3_0_pre3, no changes expected.
@rovere @VinInn @felicepantaleo @JanFSchulte @ebrondol