Update tracking validation for phase1

[makortel]

This PR updates tracking validation / MultiTrackValidator for phase1:

• extend the eta range to -3..3 for eta plots (for phase1 only)
• as knock-on effect, use TrackingParticles for efficiency vs. hits, layers, py, and DeltaR with the selector used for "vs. phi" histograms instead of "vs. eta" histograms
  • in order to keep these histograms unaffected by the eta range adjustments

In addition, the construction of "lite tracking validator" is moved from globalVaidation_cff.py to TrackValidation_cff.py to build it without dependence on era (and this way there are higher chances for being maintained for changes in tracking validation).

Tested in CMSSW_8_0_X_2016-02-02-2300. No changes expected for run2. For phase1, the only expected change is the added range for eta plots.

@rovere @VinInn

[cmsbuild]

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

It involves the following packages:

Validation/Configuration
Validation/RecoTrack

@civanch, @cvuosalo, @mdhildreth, @cmsbuild, @deguio, @slava77, @vanbesien, @davidlange6 can you please review it and eventually sign? Thanks.
@GiacomoSguazzoni, @rovere, @VinInn, @cerati, @wmtford, @istaslis, @dgulhan this is something you requested to watch as well.
@slava77, @Degano, @smuzaffar you are the release manager for this.

cms-bot commands are list here #13028

[makortel]

@davidlange6 This PR fixes one of the eras.phase1Pixel.isChosen() added in #12806. I left the other (in TrackValidation_cff.py) for now while waiting comments from @Dr15Jones (since he wasn't happy with replacing the isChosen() with toModify() here).

[Dr15Jones]

I got slowed down in the TrackValidation_cff.py changes becuase I had changed the version before your changes so now I need to start from the correct version. <sigh/>

[slava77]

@cmsbuild please test

[cmsbuild]

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

[Dr15Jones]

@makortel looking at
https://github.com/cms-sw/cmssw/blob/CMSSW_8_0_X/Validation/RecoTrack/python/TrackValidation_cff.py

I'm confused as to what happens if eras.phase1Pixel and eras.fastSim are both chosen? It looks like all the changes done in _seedProducers for when eras.fastSim is chosen are lost.

[cmsbuild]

+1
Tested at: d66eebf
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13172/10980/summary.html

[cmsbuild]

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

[makortel]

@Dr15Jones AFAIK FastSim does not work (or has not been tested) for phase1 anyway at the moment (maybe @lveldere can enlighten?). But you have a good point, this is something we have to take care of. For this particular case, the swapping the comparisons of fastSim (lines 66-74) and phase1Pixel (75-113) eras should be sufficient.

In general I wouldn't be surprised if we end up needing different FastSim customizations for run2 and phase1Pixel.

[Dr15Jones]

So I worked on TrackValidation_cff.py and what I came up with can be seen at

Dr15Jones@f4cfbcb

The configuration always adds exactly the same names to the python global name space no matter what era has been activated. You can also explicitly see if an item is modified by an era since the modification is always next to where the item is declared.

[lveldere]

@makortel

Indeed, FastSim is not ready yet for phase1 upgrade.
We start working on it next month.

BTW: FastSim also has no run1 configuration for tracking,
and we keep it that way until someone really needs it.
That will probably never happen.

[makortel]

@Dr15Jones Thanks. I gave some comments on the commit (one being a possible bug). I think it is an acceptable solution, especially if the set of modules and sequences defined in the _cff.py needs to be independent of era. The only thing I dislike a bit is that for each era one needs to copy-paste+modify lines through the file, but ok, adding eras should be rather infrequent. Do you want to make a PR for it, should I pick it here, or how should we proceed?

[Dr15Jones]

I made the fix you pointed out and forced an update. The new code can be found here

Dr15Jones@0cfe2b4

It doesn't matter to me how to proceed. Maybe it would just be cleaner if it just went into this pull request? That way the whole conversion comes in one chunk?

[cmsbuild]

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

[cmsbuild]

+1
Tested at: 3ff90e6
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13172/10999/summary.html

[cmsbuild]

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

[slava77]

+1

for #13172 3ff90e6

• code changes are in line with the description and the discussion related to era modifications in this thread
• jenkins tests pass and comparisons with the baseline show no differences for the tested workflows (phase 1 is not included)
• local test of 10039.0_TTbar_14TeV, 10046.0_MinBias_TuneZ2star_14TeV, 10060.0_TenMuE_0_200 show no differences in reco objects based on fwlite monitoring; the DQM comparisons show a lot of MTV plots changing outside the range of the baseline histogram most (all?) related to the eta range; what fits in the range appears to have only numerical differences.
  e.g. 10039 (left is the baseline)
  

[deguio]

+1

[civanch]

+1

[cmsbuild]

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

[davidlange6]

+1