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

HGCAL Clue algorithm 106 x #26194

Merged
merged 15 commits into from Apr 2, 2019
Merged

HGCAL Clue algorithm 106 x #26194

merged 15 commits into from Apr 2, 2019

Conversation

rovere
Copy link
Contributor

@rovere rovere commented Mar 15, 2019

PR description:

This PR is (re)based on top of #26099. It includes several changes:

  • The HGCAL clustering algorithms are now treated as plugins used by the central LayerCluster producer. This required quite some files reshuffling around packages.
  • The Validation of the configuration of the algorithm is done using the central Plugin Parameter Validation.
  • The default clustering algorithm has been changed. Now we use the CLUE (clustering energy) algorithm. The results of this are much better if compared to the up-to-now default one. Results have been presented in the HGCAL DPG Meeting See here, slides 42 onward

PR validation:

Tested using:

  • scram b code-checks
  • runTheMatrix.py -l limited -i all

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@slava77
Copy link
Contributor

slava77 commented Mar 15, 2019

@rovere
please add "HGCAL" somewhere in the title of the PR.
Thank you.

@rovere rovere changed the title Clue algorithm 106 x HGCAL Clue algorithm 106 x Mar 15, 2019
@rovere
Copy link
Contributor Author

rovere commented Mar 15, 2019

@rovere
please add "HGCAL" somewhere in the title of the PR.
Thank you.

Done.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26194/8791

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @rovere (Marco Rovere) for master.

It involves the following packages:

DataFormats/EgammaReco
RecoEgamma/EgammaTools
RecoLocalCalo/HGCalRecAlgos
RecoLocalCalo/HGCalRecProducers
Validation/Configuration
Validation/HGCalValidation

@perrotta, @andrius-k, @kmaeshima, @schneiml, @civanch, @kpedro88, @cmsbuild, @jfernan2, @fioriNTU, @slava77, @mdhildreth can you please review it and eventually sign? Thanks.
@edjtscott, @vandreev11, @Sam-Harper, @sethzenz, @felicepantaleo, @jainshilpi, @kpedro88, @lgray, @cseez, @bsunanda, @pfs, @argiro, @varuns23 this is something you requested to watch as well.
@davidlange6, @slava77, @fabiocos you are the release manager for this.

cms-bot commands are listed here

@slava77
Copy link
Contributor

slava77 commented Mar 15, 2019

@cmsbuild please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Mar 15, 2019

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/33613/console Started: 2019/03/15 14:23

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-26194/33613/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 1230 differences found in the comparisons
  • DQMHistoTests: Total files compared: 32
  • DQMHistoTests: Total histograms compared: 3114829
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3114631
  • DQMHistoTests: Total skipped: 197
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 121649.325 KiB( 31 files compared)
  • DQMHistoSizes: changed ( 21234.0,... ): 40549.775 KiB HGCAL/HGCalValidator
  • Checked 133 log files, 14 edm output root files, 32 DQM output files

@civanch
Copy link
Contributor

civanch commented Mar 19, 2019

+1

@andrius-k
Copy link

+1
No new changes for DQM.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-26194/33830/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 1230 differences found in the comparisons
  • DQMHistoTests: Total files compared: 32
  • DQMHistoTests: Total histograms compared: 3134059
  • DQMHistoTests: Total failures: 298
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3133564
  • DQMHistoTests: Total skipped: 197
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 31 files compared)
  • Checked 133 log files, 14 edm output root files, 32 DQM output files

@perrotta
Copy link
Contributor

Looking at the jenkins automatic comparisons, this seems a net improvement to me, with the unphysical peak at cluster energy = 1 now disappeared and spread over lower values (wf20034, TTbar14TeV2023D17)

image

Overall, there are now significantly more clusters, superclusters, etc., with some peculiar geometrical structure:

image

image

image

image

@perrotta
Copy link
Contributor

@rovere rovere mentioned this pull request Mar 29, 2019
@rovere
Copy link
Contributor Author

rovere commented Mar 29, 2019

Ciao @perrotta thanks for looking into this. From a quick look at the plots I see that the "empy" ones are related mainly to duplicates, fakes and distancetoseedcell. This is expected due to the better performance on CLUE. In the old implementation a single fluctuation of noise would have resulted in a cluster, most likely either a fake or a duplicate. Those now, are gone for good.
Nothing suspicious from my side, especially taking into accout the limited statistics.

Density getDensity();
Density getDensity() override;

static void fillPSetDescription(edm::ParameterSetDescription& iDesc) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This PSet description is the same as the one above for HGCalCLUEAlgo (a part the different numerical values for "deltac"): shouldn't this method be included in the base class, instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@perrotta this is true for the moment. There is work ongoing to try and factor few parameters out depending on which part of the detector you are in. And, for sure, the scintillator part will have to be further investigated. Coupling the PSet together means to verify, everytime we change them or add anything, that the old algorithm still works as expected, which is something I do not think is useful. I therefore propose to decouple them completely, if you agree.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, but I'm missing the point.
Even if you have the parameter set description in common, the actual configurations will be different in the two cases. And if one algo needs some extra parameter not needed by the other algo, that parameter can be added to the pset description of one algo and not to the pset description of the other one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The shared and commonly used parameters would have to be validated twice, and, very likely, the working points will be different for the different algorithm. Also, if we introduce new parameters we will likely remove other but, if the 2 are coupled, we could not do that and will end up having stale parameters in one of the 2.

@slava77
Copy link
Contributor

slava77 commented Mar 29, 2019 via email

@kpedro88
Copy link
Contributor

kpedro88 commented Apr 1, 2019

+upgrade

@perrotta
Copy link
Contributor

perrotta commented Apr 1, 2019

+1

  • The move of the clustering algorithms as plugins, and the new default CLUE clustering algo are implemented according to the description and the presentation at the reco meeting
  • Jenkins tests pass and show differences for the hgcal clusters, and derived electrons: results are in line with the expectations
  • The timing of the new default clustering algorithm looks even faster than the previous one: with some 100 events from wf 20034.0 (TTbar_14TeV with 2023D17 geometry) the hgcalLayerClusters module is faster by some 10% (from 109 to 97 ms/evt), while other module's times remain basically unchanged

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 1, 2019

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, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

@fabiocos
Copy link
Contributor

fabiocos commented Apr 2, 2019

+1

@cmsbuild cmsbuild merged commit fa467bf into cms-sw:master Apr 2, 2019
@rovere rovere deleted the CLUEAlgorithm_106X branch October 3, 2023 07:44
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.

None yet

8 participants