Pull request ExternalDecay plugins to add to 6_2_X

[inugent]

This pull request mirrors the changes made in 5_3_X, minus the TauSpinnerInterface because it 6_2_X is using Tauola++ 1.0.5 which does not have this functionality yet. Once these changes are in 6_2_X we can move to newer versions of the Tauola++ without breaking anything (ie Add TauSpinner). I recommend the same procedure as 5_3_X were we built a special release for Relval and then merge into 6_2_X after the full relVal.

[cmsbuild]

A new Pull Request was created by @inugent for CMSSW_6_2_X.

Pull request ExternalDecay plugins to add to 6_2_X

It involves the following packages:

GeneratorInterface/EvtGenInterface
GeneratorInterface/ExternalDecays
GeneratorInterface/Herwig6Interface
GeneratorInterface/PhotosInterface
GeneratorInterface/TauolaInterface
TauAnalysis/MCEmbeddingTools

The following packages do not have a category, yet:

GeneratorInterface/EvtGenInterface
GeneratorInterface/PhotosInterface
GeneratorInterface/TauolaInterface

@vciulli, @civanch, @nclopezo, @mdhildreth, @cmsbuild, @bendavid, @Degano, @ktf can you please review it and eventually sign? Thanks.
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.
@davidlt you are the release manager for this.

[bendavid]

Hi Ian,
In order to minimize the number of validation steps, would it be feasible/sensible to combine this together with both the updated tauola++ in 62x as well as the corresponding TauSpinner addition?
(Then the full set of changes could be validated in a special 62x release in one step.)

[inugent]

Hello,
Yes and no. The number of pull requests will be minimized, however, we still need two separate validations. One for backward compatibility and one that the new version if tauola++ is running correctly. Since we plan on having two or more versions of tauola++ we have to validate both (ie same number of relval). For the TauSpinner I have to validate this myself. You can not do this with relval. With the current version I can show identical results between using plugins and the old method.

Sent from my iPhone

On Jan 19, 2014, at 4:16 AM, Josh Bendavid notifications@github.com wrote:

Hi Ian,
In order to minimize the number of validation steps, would it be feasible/sensible to combine this together with both the updated tauola++ in 62x as well as the corresponding TauSpinner addition?
(Then the full set of changes could be validated in a special 62x release in one step.)

—
Reply to this email directly or view it on GitHub.

[inugent]

Sorry my iPhone sent it before I was finished...
See below

Sent from my iPhone

On Jan 19, 2014, at 10:58 AM, Ian Nugent inugent@uvic.ca wrote:

Hello,
Yes and no. The number of pull requests will be minimized, however, we still need two separate validations. One for backward compatibility and one that the new version if tauola++ is running correctly. Since we plan on having two or more versions of tauola++ we have to validate both (ie same number of relval). For the TauSpinner I have to validate this myself. You can not do this with relval. With the current version I can show identical results between using plugins and the old method.
I would also argue that breaking it down is simpler if there is a problem.
Also the TauSpinner code can be directly copied from 5-3-x to 6-2-x when the correct version of tauola is in. Maybe we can discuss this on Monday and come up with a plan that works got both of us. Best regards,
Ian

Sent from my iPhone

On Jan 19, 2014, at 4:16 AM, Josh Bendavid notifications@github.com wrote:

Hi Ian,
In order to minimize the number of validation steps, would it be feasible/sensible to combine this together with both the updated tauola++ in 62x as well as the corresponding TauSpinner addition?
(Then the full set of changes could be validated in a special 62x release in one step.)

—
Reply to this email directly or view it on GitHub.

[bendavid]

Hi Ian,
Ok, I think this is fine actually. We will discuss the request for a special 62x release and dedicated relval in the ORP on Tuesday.

[civanch]

+1

[cmsbuild]

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2075/10/summary.html

[vciulli]

+1

I am ok in moving forward with the redesign. Updating Tauola++ version later on however will break backward compatibility (but most probably we haven't generated any sample with Tauola++ in 62X yet)

[inugent]

Hello,
Well, not really. I have factorized things so it should be backward compatible. You will just get extra features. Best regards,
Ian

[vciulli]

After some discussion, what we would need to test are the following workflows, with at least 100k events each, and with comparison plots with the baseline release

#503.0 TT_TuneZ2star_8TeV_pythia6-evtgen+HARVGEN [1]:
cmsDriver.py TT_TuneZ2star_8TeV_pythia6_evtgen_cff --conditions auto:startup -s GEN,VALIDATION:genvalid --datatier GEN --relval 1000000,20000 -n 1000 --eventcontent RAWSIM
#504.0 DYToLL_M-50_TuneZ2star_8TeV_pythia6-tauola+HARVGEN [1]:
cmsDriver.py DYToLL_M_50_TuneZ2star_8TeV_pythia6_tauola_cff --conditions auto:startup -s GEN,VALIDATION:genvalid_dy --datatier GEN --relval 1000000,20000 -n 1000 --eventcontent RAWSIM
#505.0 WToLNu_TuneZ2star_8TeV_pythia6-tauola+HARVGEN [1]:
cmsDriver.py WToLNu_TuneZ2star_8TeV_pythia6_tauola_cff --conditions auto:startup -s GEN,VALIDATION:genvalid_w --datatier GEN --relval 1000000,20000 -n 1000 --eventcontent RAWSIM
#520.0 TTJets_TuneZ2star_8TeV_madgraph-tauola+HARVGEN [1]:
cmsDriver.py Hadronizer_MgmMatchTuneZ2star_8TeV_madgraph_tauola_cff --conditions auto:startup --filein lhe:5502 -s GEN,VALIDATION:genvalid --datatier GEN --relval 1000000,20000 -n 1000 --eventcontent RAWSIM
#521.0 WJetsLNu_TuneZ2star_8TeV_madgraph-tauola+HARVGEN [1]:
cmsDriver.py Hadronizer_MgmMatchTuneZ2star_8TeV_madgraph_tauola_cff --conditions auto:startup --filein lhe:5607 -s GEN,VALIDATION:genvalid_w --datatier GEN --relval 1000000,20000 -n 1000 --eventcontent RAWSIM
#522.0 ZJetsLL_TuneZ2star_8TeV_madgraph-tauola+HARVGEN [1]:
cmsDriver.py Hadronizer_MgmMatchTuneZ2star_8TeV_madgraph_tauola_cff --conditions auto:startup --filein lhe:5591 -s GEN,VALIDATION:genvalid_dy --datatier GEN --relval 1000000,20000 -n 1000 --eventcontent RAWSIM

This is what was done running RelVals for a similar change of ExternalDecays in the 5_3_X candidate release.
If it can be achieved with the jenkins test on the IB + this pull it is ok for us.
However, even if these workflows are GEN only, most probably it would take quite some time to run them on a single machine.
We can discuss at the ORP the best way to proceed.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_6_2_X IBs unless changes (tests are also fine). @Degano can you please take care of it?

[davidlange6]

+1