Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
- 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)
Merge request reports
Activity
added Calo thread-safety labels
- Resolved by Software for LHCb
/ci-test --merge
added 1 commit
- 0b82259c - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 1 commit
- 2584d222 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 1 commit
- 6f30ff7a - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 1 commit
- 121245e4 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 1 commit
- c58a2312 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
mentioned in issue Moore#141 (closed)
- Resolved by Gerhard Raven
added 24 commits
-
c58a2312...fccb9c76 - 23 commits from branch
master
- 6c4eec71 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
c58a2312...fccb9c76 - 23 commits from branch
added 5 commits
-
6c4eec71...cee29b68 - 4 commits from branch
master
- 84adbae8 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
6c4eec71...cee29b68 - 4 commits from branch
assigned to @sakar
added 29 commits
-
84adbae8...d57739be - 28 commits from branch
master
- 9379f39d - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
84adbae8...d57739be - 28 commits from branch
added 40 commits
-
9379f39d...559acc38 - 39 commits from branch
master
- 1fa15b00 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
9379f39d...559acc38 - 39 commits from branch
added 1 commit
- dd49e6b5 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 1 commit
- 1fa15b00 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
mentioned in issue Moore#148 (closed)
added 189 commits
-
1fa15b00...fb7183b9 - 188 commits from branch
master
- aa84c8da - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
1fa15b00...fb7183b9 - 188 commits from branch
added 1 commit
- 3dd212fe - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 25 commits
-
3dd212fe...9b3e618e - 24 commits from branch
master
- 0f3d05bd - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
3dd212fe...9b3e618e - 24 commits from branch
added 9 commits
-
0f3d05bd...c290cfb8 - 8 commits from branch
master
- 90ad1656 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
0f3d05bd...c290cfb8 - 8 commits from branch
added 1 commit
- b3e26479 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 1 commit
- 603e2933 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
added 4 commits
-
603e2933...1f316005 - 3 commits from branch
master
- cf0abd85 - Make ICaloFutureDigitFilterTool threadsafe, streamline counters in CaloCorrections
-
603e2933...1f316005 - 3 commits from branch
added 1 commit
- addf015c - change Photon and Pi0Tools to be private instead of public
mentioned in commit Moore@55b50b02
mentioned in merge request Moore!490 (merged)
mentioned in commit Moore@e43d2226
added 1 commit
- 31fafb1e - change Photon and Pi0Tools to be private instead of public
assigned to @sgweber
unassigned @sakar
@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.
- [2020-05-07 21:59] Validation started with lhcb-master-mr#787
- [2020-05-08 13:20] Validation started with lhcb-master-mr#791
- [2020-05-08 16:04] Validation started with lhcb-master-mr#793
- [2020-05-12 00:15] Validation started with lhcb-gaudi-head#2598
- [2020-05-13 00:15] Validation started with lhcb-gaudi-head#2599
Edited by Software for LHCbadded 1 commit
- 44989462 - move corrections in ClassifyPhotonElectronAlg to be private tools
mentioned in commit Moore@533766d5
added 1 commit
- 61c8aac5 - move corrections in ClassifyPhotonElectronAlg to be private tools
- 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
- Resolved by Gerhard Raven
added needs ref update label
mentioned in issue Moore#168 (closed)
added lhcb-gaudi-head label