Skip to content
Snippets Groups Projects

Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

Merged Gerhard Raven requested to merge threadsafe-calofuturedigitfiltertool into master
  • remove use of cached pileup determination & use of incident service
  • add helper function to make sets of counters per calo area
  • prefer ToolHandles over tool<...>(...)
  • prefer DataObjectReadHandle over getIfExists<...>(...)
  • amalgamate component header files into their corresponding source files

must be applied in conjunction with Moore!490 (merged)

references updated in Brunel!1020 (merged) and Moore!496 (merged)

Edited by Roel Aaij

Merge request reports

Pipeline #1635863 passed

Pipeline passed for cdf86ce1 on threadsafe-calofuturedigitfiltertool

Merged by Christopher Rob JonesChristopher Rob Jones 4 years ago (May 19, 2020 12:46pm UTC)

Merge details

  • Changes merged into master with fa7684b5.
  • Deleted the source branch.

Pipeline #1645532 passed

Pipeline passed for fa7684b5 on master

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Gerhard Raven added 24 commits

    added 24 commits

    • c58a2312...fccb9c76 - 23 commits from branch master
    • 6c4eec71 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 5 commits

    added 5 commits

    • 6c4eec71...cee29b68 - 4 commits from branch master
    • 84adbae8 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • assigned to @sakar

  • Gerhard Raven added 29 commits

    added 29 commits

    • 84adbae8...d57739be - 28 commits from branch master
    • 9379f39d - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 40 commits

    added 40 commits

    • 9379f39d...559acc38 - 39 commits from branch master
    • 1fa15b00 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven marked as a Work In Progress

    marked as a Work In Progress

  • Gerhard Raven added 1 commit

    added 1 commit

    • dd49e6b5 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • 1fa15b00 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • mentioned in issue Moore#148 (closed)

  • Gerhard Raven added 189 commits

    added 189 commits

    • 1fa15b00...fb7183b9 - 188 commits from branch master
    • aa84c8da - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • 3dd212fe - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 25 commits

    added 25 commits

    • 3dd212fe...9b3e618e - 24 commits from branch master
    • 0f3d05bd - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 9 commits

    added 9 commits

    • 0f3d05bd...c290cfb8 - 8 commits from branch master
    • 90ad1656 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • b3e26479 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • 603e2933 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 4 commits

    added 4 commits

    • 603e2933...1f316005 - 3 commits from branch master
    • cf0abd85 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • addf015c - change Photon and Pi0Tools to be private instead of public

    Compare with previous version

  • Gerhard Raven unmarked as a Work In Progress

    unmarked as a Work In Progress

  • mentioned in commit Moore@55b50b02

  • Gerhard Raven mentioned in merge request Moore!490 (merged)

    mentioned in merge request Moore!490 (merged)

  • mentioned in commit Moore@e43d2226

  • Gerhard Raven added 1 commit

    added 1 commit

    • 31fafb1e - change Photon and Pi0Tools to be private instead of public

    Compare with previous version

  • assigned to @sgweber

  • unassigned @sakar

  • Gerhard Raven changed the description

    changed the description

  • Author Developer

    @ldufour : I expect that this MR may just fix the crash which looked like it was due to a data race...

    In more detail: this removes the use of the incident listener which, at the start of each event, would check whether new constants should be loaded from the conditions DB -- but in multithreaded running, the 'start of event' is not well defined, and can lead to one thread triggering the loading of new constants while another thread is still using the old ones.

  • Gerhard Raven resolved all threads

    resolved all threads

  • Edited by Software for LHCb
  • Gerhard Raven added 1 commit

    added 1 commit

    • 3c7e4f99 - remove unneccessary mutable/const, Warning

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • fcdcd62d - remove unneccessary mutable/const, Warning

    Compare with previous version

  • Gerhard Raven added 1 commit

    added 1 commit

    • 44989462 - move corrections in ClassifyPhotonElectronAlg to be private tools

    Compare with previous version

  • mentioned in commit Moore@533766d5

  • Gerhard Raven added 1 commit

    added 1 commit

    • 61c8aac5 - move corrections in ClassifyPhotonElectronAlg to be private tools

    Compare with previous version

    • Author Developer
      Resolved by Gerhard Raven

      Looking at the counter changes in the MR, I see something I don't quite understand. For example, one difference is the following:

      -ToolSvc.LCorrec...SUCCESS Number of counters : 10
      +ClassifyPhotonE...SUCCESS Number of counters : 10
        |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
      - | "<delta> Inner"                                 |      3462 |   281249.1 |     81.239 |    0.50161 |      81.241 |      81.241 |
      - | "<delta> Middle"                                |      3194 |   304395.8 |     95.302 |    0.10391 |      95.304 |      95.304 |
      - | "<delta> Outer"                                 |      6818 |     742312 |     108.88 |     1.1753 |      108.88 |      108.88 |
      - | "<gamma> Inner"                                 |      3462 |   51159.43 |     14.777 |   0.082980 |      14.778 |      14.778 |
      - | "<gamma> Middle"                                |      3194 |   46104.43 |     14.435 |   0.097077 |      14.435 |      14.435 |
      - | "<gamma> Outer"                                 |      6818 |    99645.8 |     14.615 |     0.0000 |      14.614 |      14.614 |
      - | "Delta(Z)"                                      |     13474 |    1457096 |     108.14 |     11.873 |      74.662 |      161.77 |
      - | "Delta(Z) Inner"                                |      3462 |     373831 |     107.98 |     12.139 |      77.351 |      150.92 |
      - | "Delta(Z) Middle"                               |      3194 |   342780.9 |     107.32 |     10.739 |      79.642 |      149.25 |
      - | "Delta(Z) Outer"                                |      6818 |   740488.9 |     108.61 |     12.211 |      74.662 |      161.77 |
      -ToolSvc.SCorrec...SUCCESS Number of counters : 2
      + | "<delta> Inner"                                 |      3462 |   281256.8 |     81.241 |     0.0000 |      81.241 |      81.241 |
      + | "<delta> Middle"                                |      3194 |   304400.9 |     95.304 |   0.079207 |      95.304 |      95.304 |
      + | "<delta> Outer"                                 |      6818 |   742330.1 |     108.88 |    0.14002 |      108.88 |      108.88 |
      + | "<gamma> Inner"                                 |      3462 |   51160.76 |     14.778 |   0.011456 |      14.778 |      14.778 |
      + | "<gamma> Middle"                                |      3194 |   46104.81 |     14.435 |  0.0086922 |      14.435 |      14.435 |
      + | "<gamma> Outer"                                 |      6818 |   99640.88 |     14.614 |   0.010837 |      14.614 |      14.614 |
      + | "Delta(Z)"                                      |     13474 |    1457099 |     108.14 |     11.872 |      74.662 |      161.77 |
      + | "Delta(Z) Inner"                                |      3462 |   373830.7 |     107.98 |     12.139 |      77.351 |      150.92 |
      + | "Delta(Z) Middle"                               |      3194 |   342780.6 |     107.32 |     10.741 |      79.642 |      149.25 |
      + | "Delta(Z) Outer"                                |      6818 |   740487.5 |     108.61 |     12.213 |      74.662 |      161.77 |
      +ClassifyPhotonE...SUCCESS Number of counters : 2

      where the - is the old setup, with public tools, and the + is the new one with private tools. Now, take a look at eg the first one, <delta> Inner -- in both, the 'min' and 'max' are equal and the same, i.e. four times 81.241. But in the 'new' setup, the mean is also 81.241, but in the 'old' setup, the mean is 81.239, which is smaller than 'min'. Can anyone give me an example of a distribution where the mean is smaller than the smallest entry? In addition, the min and max are equal, but the rms = 0.5, which is at least two orders of magnitude greater than the possible difference between min and max, assuming that they are only equal due to rounding... At least in the 'new' configuration, the RMS is zero... Next, take the sum and divide by the number of entries -- in the 'old' setup, this gives 81.23890814558058, which is not equal to the mean. Again, in the new setup the sum divided by the number of entries is the mean...

      Edited by Gerhard Raven
  • Gerhard Raven resolved all threads

    resolved all threads

  • Steffen Georg Weber assigned to @raaij and unassigned @sgweber

    assigned to @raaij and unassigned @sgweber

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading