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

TICL: Create PF candidates as output of TICL #28116

Merged
merged 18 commits into from Oct 23, 2019
Merged

Conversation

steggema
Copy link
Contributor

@steggema steggema commented Oct 4, 2019

PR description:

This PR prepares the integration of TICL into CMS Particle Flow by creating PFCandidates that can subsequently be integrated in the central CMS PF collection. It does so with the help of an intermediate data format, the TICLCandidate, by converting the TICL output (a list of tracksters) into TICLCandidates, and subsequently the TICLCandidates into regular PFCandidates. It also adds DQM plots for the such-produced PFCandidates.

Presentations were given in a RECO/AT meeting, https://indico.cern.ch/event/841640/contributions/3539177/attachments/1896768/3129567/2019_08_23_reco.pdf, and in an HGCAL DPG meeting, https://indico.cern.ch/event/849004/contributions/3567562/attachments/1910534/3156782/2019_09_18_hgcal_dpg.pdf

PR validation:

The workflow has been validated by enabling TICL as defined in RecoHGCal/TICL/python/ticl_iterations.py and checking the DQM output.

if this PR is a backport please specify the original PR: -

@rovere @felicepantaleo @bendavid @hatakeyamak (HGCal RECO and PF)

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 4, 2019

The code-checks are being triggered in jenkins.

@felicepantaleo
Copy link
Contributor

please test workflow 20493.52

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 4, 2019

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28116/12139

  • This PR adds an extra 84KB to repository

  • Found files with invalid states:

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 4, 2019

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/2788/console Started: 2019/10/04 18:11

@cmsbuild
Copy link
Contributor

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

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 34
  • DQMHistoTests: Total histograms compared: 2961056
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2960714
  • DQMHistoTests: Total skipped: 341
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
  • Checked 147 log files, 16 edm output root files, 34 DQM output files

@jfernan2
Copy link
Contributor

+1

@kpedro88
Copy link
Contributor

+upgrade

@rovere
Copy link
Contributor

rovere commented Oct 15, 2019

@perrotta @slava77
A kind reminder.

@perrotta
Copy link
Contributor

you are right @steggema , adding the top level BuildFile instructs scram to build a shared library RecoHGCalTICL and this cause scram to also test headers files using the dependency list of top level BuildFile. Please move the headers in plugins directory and drop top level BuildFile too. It is only needed when you want to build a public shared library

@steggema , I am belatedly late in jumping in this PR. Looking at the thread I see this comment from @smuzaffar which suggests to move all headers into the \plugin directory, and drop the top level BuildFile too.
As of now, I see that still TracksterMomentumPluginBase and TracksterTrackPluginBase sit in the \interface (and \src) directories, although being only used by the new plugins here: this prevents removing the top level Buildfile.

I see that this PR does not fail the headers check any more, and therefore it should be considered as technically fixed. However, I would like to get confirmation from @smuzaffar that he is fine with the current arrangements. or if it would still be preferable to move to \plugin whatever is not needed to build a public shared library.

#include "RecoHGCal/TICL/interface/TracksterMomentumPluginBase.h"
#include "FWCore/Framework/interface/MakerMacros.h"

EDM_REGISTER_PLUGINFACTORY(TracksterMomentumPluginFactory, "TracksterMomentumPluginFactory");
Copy link
Contributor

Choose a reason for hiding this comment

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

this is wrong, we shoud never register a plugin from a shared library

Copy link
Contributor

Choose a reason for hiding this comment

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

@smuzaffar this is registering a factory, not a plugin. Doesn't this need to be in a shared library to be accessible?

Copy link
Contributor

Choose a reason for hiding this comment

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

ah did not realize that @kpedro88 . Looking at cmssw , yes plugin factories are ok to be in shared libs.

#include "RecoHGCal/TICL/interface/TracksterTrackPluginBase.h"
#include "FWCore/Framework/interface/MakerMacros.h"

EDM_REGISTER_PLUGINFACTORY(TracksterTrackPluginFactory, "TracksterTrackPluginFactory");
Copy link
Contributor

Choose a reason for hiding this comment

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

this is wrong, we shoud never register a plugin from a shared library

Copy link
Contributor

Choose a reason for hiding this comment

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

ignore the above comment

@smuzaffar
Copy link
Contributor

@steggema and @perrotta , there is no need to have these interface/ src/ files. Currently these are registering edm plugins which will cause duplicate plugins if this library is linked by any other package.
Please move these to plugins/ and drop the top level BuildFile.

@steggema
Copy link
Contributor Author

@perrotta From the updated responses, I understand that there's no action required from my side. Please let me know if I misunderstood.

@rovere
Copy link
Contributor

rovere commented Oct 22, 2019

From the last time I checked, pre11 is due today and it would be a pity if this Pr is not part of it.
Also, could someone confirm if this is still the confirmed schedule for CMSSW_11

@perrotta
Copy link
Contributor

@perrotta From the updated responses, I understand that there's no action required from my side. Please let me know if I misunderstood.

Yes, as far as I understand @smuzaffar does not ask any more to move everything into the plugin directory and remove the top level Buildfile.
I just checked with him because that comment wasn't answered at the time.

@smuzaffar
Copy link
Contributor

smuzaffar commented Oct 22, 2019

true, PR is its current state looks good. No need to move top level buildfile or interface, src files. headers file checks look good too.

@perrotta
Copy link
Contributor

The footprint on CPU time and output size of this PR is quite limited, at least for the non PU workflow 20493.52

  • The addition to the AOD output is limited to the two new branches, with an overall contribution to the total size which is of the order of permil
-----------------------------------------------------------------
   or, B         new, B      delta, B   delta, %   deltaJ, %    branch 
-----------------------------------------------------------------
      0.0 ->       199.0        199     NEWO   0.06     recoPFCandidates_pfTICLProducer__RECO.
      0.0 ->       255.1        255     NEWO   0.07     TICLCandidates_ticlCandidateFromTrackstersProducer__RECO.
-------------------------------------------------------------
   351284 ->      351737        454             0.1     ALL BRANCHES
  • Nothing is added, for the moment, to the minAOD output

  • The CPU consumptions of the new modules is minimal:

  delta/mean delta/orJob     original                   new       module name
  ---------- ------------     --------                  ----       ------------
       added      +0.00%         0.00 ms/ev ->         0.02 ms/ev ticlPFValidation
       added      +0.00%         0.00 ms/ev ->         0.03 ms/ev pfTICLProducer
       added      +0.00%         0.00 ms/ev ->         0.02 ms/ev ticlCandidateFromTrackstersProducer
  ---------- ------------     --------                  ----       ------------
Job total:  1.00444 s/ev ==> 1.00693 s/ev

@perrotta
Copy link
Contributor

+1

  • TICLCandidate's are created as intermediate step tpowards PF candidates
  • The implementation corresponds to what anticipated in the PR description, and also takes into account the following review
  • Jenkins tests show that "normal" Phase2 workflows are not affected, while for workflows in which TICL reconstruction is activated the expected products show up in output

@cmsbuild
Copy link
Contributor

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

+1

@cmsbuild cmsbuild merged commit 5a7a185 into cms-sw:master Oct 23, 2019
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