updated GEN-SIM input; fixed HI wf's INPUT

[fabozzi]

updated GEN-SIM recycling
fixed GEN-SIM INPUT for HI wf's

[cmsbuild]

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

updated GEN-SIM input; fixed HI wf's INPUT

It involves the following packages:

Configuration/PyReleaseValidation

@cmsbuild, @srimanob, @nclopezo, @boudoul, @franzoni can you please review it and eventually sign? Thanks.
@ghellwig, @Martin-Grunewald 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, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[cmsbuild]

+1
Tested at: 03aac0d
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8016/6359/summary.html

[franzoni]

hello @kkrajcza,
The workflow 280 runs the proton-proton DIGI and RECO, which was a deliberate choice;
is the reco beamspot provided by the GT auto:run1_mc consistent with the SIM beamspot Realistic5TeVPPbBoost ?
Cheers. G.

[cmsbuild]

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

[mandrenguyen]

@franzoni

Good catch, the answer is no.
This is a pPb workflow and pPb beam conditions are not currently being maintained in 74X.
We probably want to maintain this workflow, as we will eventually have pPb collisions again, and reprocessing of the 2013 data is possible (although not currently scheduled).
Maintaining the corresponding pPb GTs in 74X is probably not essential though, given the other priorities at the moment for all involved.

A stop-gap solution would be to simply use the pp beamspot corresponding to run1_mc.
This means that we would be running unboosted pPb, which is not what we record, but would at least maintain the technical viability of running the workflow (although not the boost tool).
Another solution would be to add a customize fragment to switch the beamspot.
Maybe you have a better suggestion.

[franzoni]

the two last entries in the conversation of this PR refer to another PR (the discussion has continued there)

[franzoni]

+1
all standard and premix workflows tested CMSSW_7_4_X_2015-03-01-0200
all workflows ok (except 280.0_AMPT_PPb_5020GeV_MinimumBias+AMPT_PPb_5020GeV_MinimumBias+DIGI+RECO+HARVEST which is known and being addressed by HIN)
No differences of 75x with respect to the 74 IB => the tests sufficient.

Thanks @fabozzi @nancymarinelli

[cmsbuild]

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

[davidlange6]

+1