Add more histograms and track selections to MultiTrackValidator, remove standalone mode

[makortel]

This PR makes several updates to tracking validation

• Add monitoring for BTV-like track selection
• Add monitoring for tracks used in AK4 PFJets whose corrected pT > 10 GeV
  • Add JetTracksAssociationToTrackRefs EDProducer to pick the Refs to tracks
• Add histograms for pileup track rate (fraction of tracks matched to TrackingParticles) from pileup)
• Add histograms for number of tracker layers, pixel layers, and 3D layers (=pixel+strip mono&stereo)
  • Add TrackingParticleNumberOfLayers class to calculate them from TrackingParticles
    • TP does not have a count of pixel nor strip mono&stereo layers
    • The number of tracker layers is in TP, but the calculation in TrackingTruthAccumulator is slightly misleading
      • It calculates the number of layer transitions when moving along the SimTrack inside out
      • This is incorrect at least for loopers, and for TPs with multiple SimTracks having SimHits in same layers
    • Eventually we should probably move to use HitPattern (either as a member of TP or as a ValueMap), but that is left for future development
• Add fake rate vs. track chi2
• Add summary plots for efficiency and fake rate per input track collection
• Add "standalone" sequences so that MTV-only validation configuration can be generated with cmsDriver
• Add configuration flags controlling which sets of histograms are booked and filled
  • Not employed in this PR, but will be used in subsequent development
• Remove the obsolete standalone-mode of MultiTrackValidator
  • This mode allowed to produce efficiencies etc. in the same job as histograms were filled, but this can not work anymore due to MT DQM, and our recommendation has been already a while to run a separate harvesting step. Getting rid of obsolete code now to ease maintenance.

Tested in CMSSW_7_5_X_2015-05-12-2300. No changes expected in existing histograms.

@rovere @VinInn

[cmsbuild]

A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_7_5_X.

Add more histograms and track selections to MultiTrackValidator, remove standalone mode

It involves the following packages:

CommonTools/RecoAlgos
FastSimulation/Validation
PhysicsTools/RecoAlgos
SLHCUpgradeSimulations/Geometry
SimGeneral/TrackingAnalysis
Validation/Configuration
Validation/RecoHI
Validation/RecoMuon
Validation/RecoTrack
Validation/RecoVertex

@civanch, @Dr15Jones, @lveldere, @cvuosalo, @ianna, @mdhildreth, @monttj, @cmsbuild, @ssekmen, @nclopezo, @deguio, @slava77, @vadler, @danduggan can you please review it and eventually sign? Thanks.
@TaiSakuma, @abbiendi, @rappoccio, @Martin-Grunewald, @venturia, @mmarionncern, @battibass, @ahinzmann, @jhgoh, @dgulhan, @jdolen, @cerati, @trocino, @schoef, @rociovilar, @kkrajczar, @GiacomoSguazzoni, @rovere, @VinInn, @nhanvtran, @wmtford, @richard-cms, @appeltel, @RylanC24, @matt-komm, @mariadalfonso 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.
@nclopezo you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[lveldere]

@makortel

Hi Matti

Will MTV-standalone via cmsDriver also work for FastSim?

Lukas

[makortel]

Hi Lukas,

Following the current construction, it would (in principle) need a separate sequence (in order to avoid tpClusterProducer in FastSim).

On the other hand, now that we explicitly set quickTrackAssociatorByHits.useClusterTPAssociation = False in TrackValidation_fastsim_cff.py, having tpClusterProducer in the sequences for FastSim should not alter the results (just wastes some CPU), so using the same sequence as in FullSim should work in practice too. If you want to try out, use ...,VALIDATION:tracksValidationStandalone,... in cmsDriver.

Anyway, now that you wrote it, if it doesn't work for FastSim already, I think it should be made to work.

[makortel]

(Just thinking out loud) Should we then envision a massive migration campaign to transform e.g. all/most instantiations of ObjectSelector from EDFilter to EDProducer?