Update TrackingParticleFactory::vectorIsInsideVolume(...) function in TrackingTruthAccumulator

[jiafulow]

In the function, the check of vertex z position should be using the absolute value.

I suspect this is an accidental bug. It should not affect anyone who uses official samples, and it should not affect any validation plots because the default in trackingTruthProducer_cfi.py has

    ignoreTracksOutsideVolume = cms.bool(False)

When the switch is false, the check of vertex position is not done. It only matters when a person decides to switch it on to get only the tracking particles and tracking vertices inside the tracker, as specified by the parameters

    volumeRadius = cms.double(120.0),
    volumeZ = cms.double(300.0),

However, as it is, the cut on vertex z is applied as a single-sided cut, rather than as a double-sided cut. I believe the expected behavior should be the latter, but I guess it's really up to the experts to decide.

This was first discussed on the pull request #9680 . As suggested by @mark-grimes, this is a duplicated pull request, but instead for the CMSSW_7_5_X release.

[cmsbuild]

A new Pull Request was created by @jiafulow for CMSSW_7_5_X.

Update TrackingParticleFactory::vectorIsInsideVolume(...) function in TrackingTruthAccumulator

It involves the following packages:

SimGeneral/TrackingAnalysis

@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks.
@battibass, @makortel, @abbiendi, @GiacomoSguazzoni, @jhgoh, @VinInn, @appeltel, @rovere, @cerati, @trocino, @dgulhan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[mark-grimes]

I can confirm when I originally wrote the code it was intended as a two sided cut, and that it is off by default. As far as I am aware the cut has never been used - when I first tested it (3+ years ago?) I found the cut had almost no effect so assumed there was an earlier cut in the Geant4 interface code. This bug was probably at least part of it.

[civanch]

please test

[civanch]

+1

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs or unless it breaks tests. This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs or unless it breaks tests. This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[cmsbuild]

+1
Tested at: 83bd89a
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9682/5577/summary.html

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1

[cmsbuild]

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

There are some workflows for which there are errors in the baseline:
50202.0 step 2
25202.0 step 3
The results for the comparisons for these workflows could be incomplete
This means most likely that the IB is having errors in the relvals.The error does NOT come from this pull request