Initialize SpatialRange to avoid compilation warnings on PPC64LE

[smuzaffar]

PR description:

In Power IBs, we have few compilation warnings [a]. This could happen if there are no hits and https://cmssdt.cern.ch/lxr/source/RecoPPS/Local/interface/CTPPSTimingTrackRecognition.h#0198 return the un-initialized SpatialRange. This PR propose to initialize SpatialRange with default values.

[a]

RecoPPS/Local/src/TotemTimingTrackRecognition.cc: In member function 'virtual int TotemTimingTrackRecognition::produceTracks(edm::DetSet<TotemTimingLocalTrack>&)':
  RecoPPS/Local/src/TotemTimingTrackRecognition.cc:66:96: warning: 'result.CTPPSTimingTrackRecognition<TotemTimingLocalTrack, TotemTimingRecHit>::SpatialRange::zEnd' may be used uninitialized in this function [-Wmaybe-uninitialized]
          math::XYZPoint positionSigma(xTrack.x0Sigma(), yTrack.y0Sigma(), 0.5f * (hitRange.zEnd - hitRange.zBegin));
                                                                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
  RecoPPS/Local/src/TotemTimingTrackRecognition.cc:66:96: warning: 'result.CTPPSTimingTrackRecognition<TotemTimingLocalTrack, TotemTimingRecHit>::SpatialRange::zBegin' may be used uninitialized in this function [-Wmaybe-uninitialized]
 In file included from RecoPPS/Local/interface/TotemTimingTrackRecognition.h:18,
                 from RecoPPS/Local/src/TotemTimingTrackRecognition.cc:11:
  RecoPPS/Local/interface/CTPPSTimingTrackRecognition.h:131:15: warning: 'result.CTPPSTimingTrackRecognition<TotemTimingLocalTrack, TotemTimingRecHit>::SpatialRange::yEnd' may be used uninitialized in this function [-Wmaybe-uninitialized]
    const float profileRangeEnd = param.rangeEnd + profileRangeMargin;
               ^~~~~~~~~~~~~~~

PR validation:

Local compilation with both normal amd64 and ppc64le IBs is successful (without any warnings).

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29763/15210

• This PR adds an extra 12KB to repository

[smuzaffar]

please test

[cmsbuild]

A new Pull Request was created by @smuzaffar (Malik Shahzad Muzaffar) for master.

It involves the following packages:

RecoPPS/Local

@perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@silviodonato, @dpiparo you are the release manager for this.

cms-bot commands are listed here

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/6162/console Started: 2020/05/07 18:34

[cmsbuild]

+1
Tested at: c02fc28
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5d8e8e/6162/summary.html
CMSSW: CMSSW_11_1_X_2020-05-07-1100
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5d8e8e/6162/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: 2697527
• DQMHistoTests: Total failures: 32
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2697176
• DQMHistoTests: Total skipped: 319
• 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

[perrotta]

+1

• Technical: it initializes SpatialRange with default values, which will be the returned ones when there are no hits
• No changes expected: getHitSpatialRange(hits) is called in two places, and in both cases there is a check of the hits vector not being empty after that call:
  • RecoPPS/Local/src/CTPPSDiamondTrackRecognition.cc
  • RecoPPS/Local/src/TotemTimingTrackRecognition.cc
  • Therefore, even with this fix no changes are expected in outputs
• Jenkins tests pass and show no differences, as it should

[cmsbuild]

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

[perrotta]

@fabferro : while this fix should remain, wouldn't it be more convenient in the two calls pointed out above to check for the non-emptiness of the vecor of hits before calling getHitSpatialRange and producePartialTracks (instead than after them), so that useless computations can be avoided?

[fabferro]

@fabferro : while this fix should remain, wouldn't it be more convenient in the two calls pointed out above to check for the non-emptiness of the vecor of hits before calling getHitSpatialRange and producePartialTracks (instead than after them), so that useless computations can be avoided?

@perrotta that's a good question, I actually don't know if there's a reason why it's not been implemented already. I'd forward the question to the developers of the PPS timing code @forthommel @jan-kaspar

[silviodonato]

+1

[forthommel]

@fabferro : while this fix should remain, wouldn't it be more convenient in the two calls pointed out above to check for the non-emptiness of the vecor of hits before calling getHitSpatialRange and producePartialTracks (instead than after them), so that useless computations can be avoided?

Indeed, thanks @perrotta! I will tackle this in a follow-up PR.