Modify vertex validation to use timing when possible.

[lgray]

This PR modifies the vertex matching to take advantage of timing information if it is available.

Examples (red is 4D vertexing, blue is 3D):

[cmsbuild]

A new Pull Request was created by @lgray (Lindsey Gray) for CMSSW_8_1_X.

It involves the following packages:

SimTracker/VertexAssociation

@cmsbuild, @civanch, @mdhildreth, @davidlange6 can you please review it and eventually sign? Thanks.
@makortel, @sdevissc, @GiacomoSguazzoni, @rovere, @VinInn, @threus, @dgulhan this is something you requested to watch as well.
@slava77, @smuzaffar you are the release manager for this.

cms-bot commands are listed here #13028

[lgray]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/15691/console

[cmsbuild]

+1
Tested at: 4067e4b
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-16191/15691/summary.html

[cmsbuild]

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

@slava77 comparisons for the following workflows were not done due to missing matrix map:

• 10021.0_TenMuE_0_200+TenMuE_0_200_pythia8_2017_GenSimFull+DigiFull_2017+RecoFull_2017+ALCAFull_2017+HARVESTFull_2017
• 10024.0_TTbar_13+TTbar_13TeV_TuneCUETP8M1_2017_GenSimFull+DigiFull_2017+RecoFull_2017+ALCAFull_2017+HARVESTFull_2017
• 10424.0_TTbar_13+TTbar_13TeV_TuneCUETP8M1_2017NewFPix_GenSimFull+DigiFull_2017NewFPix+RecoFull_2017NewFPix+ALCAFull_2017NewFPix+HARVESTFull_2017NewFPix
• 10624.0_TTbar_13+TTbar_13TeV_TuneCUETP8M1_2017HCALdev_GenSimFull+DigiFull_2017HCALdev+RecoFull_2017HCALdev+ALCAFull_2017HCALdev+HARVESTFull_2017HCALdev
• 10824.0_TTbar_13+TTbar_13TeV_TuneCUETP8M1_2017AllNew_GenSimFull+DigiFull_2017AllNew+RecoFull_2017AllNew+ALCAFull_2017AllNew+HARVESTFull_2017AllNew

[makortel]

Thanks @lgray. I'm not entirely sure of the benefit of adding a second constructor to VertexAssociatorByPositionAndTracks though. My concern is that the EDProducer uses one convention of special values of timing parameters (< 0.0) to denote if the time matching is disabled, and the associator uses another one (std::numeric_limits<double>::max()).

Personally I'd like if the associator would use the same convention as the configuration. Then, when trying to understand what the configuration parameters actually do, one can essentially skip the code of EDProducer.

Minor point but I thought to mention.

[civanch]

@lgray , it would be more correct if useTiming flag is a class member which is defined in the constructor but not deeply inside the code. All actions when time is taken into account will be enabled by such flag.

[lgray]

@civanch This option is a bit "forward looking" in the sense that there will be an efficiency associated assigning the timing to the tracks in vertices, and it may be the case that there are some vertices without timing information. Therefore the behavior of the analyzer should be determined per-vertex.

[civanch]

+1

[cmsbuild]

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

[davidlange6]

+1

[lgray]

@makortel I agree with your statements about the constructors and consistency. I'll fix it up in another PR.

[makortel]

Thanks @lgray.