GenEventInfoProduct weights size grows at lumisection change

[peruzzim]

On request of PPD and release managers, I'm reporting here to follow up on https://its.cern.ch/jira/browse/CMSCOMPPR-8777.

It has been found that the size of the vector returned by the weights() method of GenEventInfoProduct is not constant within a MINIAOD file in the UL2017 MC production (in CMSSW_10_6_2). This was exposed by the fact that NANOAOD production code reads this object to store PS weights, as it is normally done in analysis.

Later checks showed that the issue appears already in GENSIM files (e.g. in /store/mc/RunIISummer19UL17SIM/GluGluToHiggs0Mf05ph0continToZZTo2e2tau_M125_10GaSM_13TeV_MCFM701_pythia8/SIM/106X_mc2017_realistic_v6-v2/260000/FE9FEFBF-1735-784F-B84C-338F8A41624C.root).

It was observed that the size of the vector often grows by 22 at a lumisection change, potentially up to very large numbers (~2000) - but sometimes it goes back to the expected value of 46, probably as a result of merging separate output files from an earlier production step.
On the example file above, it seems that 1.0 values somehow appear in the central part of the vector, increasing its size. The rest of the values are all close to 1 and do not show crazy values.

It was suggested that this issue could somehow be related to #25708.

@srimanob @fabiocos

[cmsbuild]

A new Issue was created by @peruzzim .

@davidlange6, @Dr15Jones, @smuzaffar, @fabiocos, @kpedro88 can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[fabiocos]

assign generators

[cmsbuild]

New categories assigned: generators

@alberto-sanchez,@qliphy,@efeyazgan,@agrohsje you have been requested to review this Pull request/Issue and eventually sign? Thanks

[Dr15Jones]

From using edmProvDump on the file in the original comment, the only GenEventInfoProduct comes from the module with the generator label in the GEN process. The provenance for that is

Module: generator GEN
 PSet id:0c838f619e572e3cae18d2ae2fb4d4f0
 products: {
  GenEventInfoProduct_generator__GEN.
  GenLumiInfoHeader_generator__GEN.
  GenLumiInfoProduct_generator__GEN.
  GenRunInfoProduct_generator__GEN.
  edmHepMCProduct_generator_unsmeared_GEN.
 }
 parameters: {
  @module_edm_type: string tracked  = 'EDFilter'
  @module_label: string tracked  = 'generator'
  @module_type: string tracked  = 'Pythia8HadronizerFilter'
  comEnergy: double tracked  = 13000
  PythiaParameters: PSet tracked = ({
   parameterSets: vstring tracked  = {'pythia8CommonSettings','pythia8CP5Settings','pythia8PSweightsSettings','processParameters'}
   processParameters: vstring tracked  = {'SpaceShower:pTmaxMatch = 1','TimeShower:pTmaxMatch = 1','SpaceShower:pTmaxFudge = 1','TimeShower:pTmaxFudge = 1'}
   pythia8CP5Settings: vstring tracked  = {'Tune:pp 14','Tune:ee 7','MultipartonInteractions:ecmPow=0.03344','MultipartonInteractions:bProfile=2','MultipartonInteractions:pT0Ref=1.41','MultipartonInteractions:coreRadius=0.7634','MultipartonInteractions:coreFraction=0.63','ColourReconnection:range=5.176','SigmaTotal:zeroAXB=off','SpaceShower:alphaSorder=2','SpaceShower:alphaSvalue=0.118','SigmaProcess:alphaSvalue=0.118','SigmaProcess:alphaSorder=2','MultipartonInteractions:alphaSvalue=0.118','MultipartonInteractions:alphaSorder=2','TimeShower:alphaSorder=2','TimeShower:alphaSvalue=0.118','SigmaTotal:mode = 0','SigmaTotal:sigmaEl = 21.89','SigmaTotal:sigmaTot = 100.309','PDF:pSet=LHAPDF6:NNPDF31_nnlo_as_0118'}
   pythia8CommonSettings: vstring tracked  = {'Tune:preferLHAPDF = 2','Main:timesAllowErrors = 10000','Check:epTolErr = 0.01','Beams:setProductionScalesFromLHEF = off','SLHA:keepSM = on','SLHA:minMassSM = 1000.','ParticleDecays:limitTau0 = on','ParticleDecays:tau0Max = 10','ParticleDecays:allowPhotonRadiation = on'}
   pythia8PSweightsSettings: vstring tracked  = {'UncertaintyBands:doVariations = on','UncertaintyBands:List = {isrRedHi isr:muRfac=0.707,fsrRedHi fsr:muRfac=0.707,isrRedLo isr:muRfac=1.414,fsrRedLo fsr:muRfac=1.414,isrDefHi isr:muRfac=0.5,fsrDefHi fsr:muRfac=0.5,isrDefLo isr:muRfac=2.0,fsrDefLo fsr:muRfac=2.0,isrConHi isr:muRfac=0.25,fsrConHi fsr:muRfac=0.25,isrConLo isr:muRfac=4.0,fsrConLo fsr:muRfac=4.0,fsr_G2GG_muR_dn fsr:G2GG:muRfac=0.5,fsr_G2GG_muR_up fsr:G2GG:muRfac=2.0,fsr_G2QQ_muR_dn fsr:G2QQ:muRfac=0.5,fsr_G2QQ_muR_up fsr:G2QQ:muRfac=2.0,fsr_Q2QG_muR_dn fsr:Q2QG:muRfac=0.5,fsr_Q2QG_muR_up fsr:Q2QG:muRfac=2.0,fsr_X2XG_muR_dn fsr:X2XG:muRfac=0.5,fsr_X2XG_muR_up fsr:X2XG:muRfac=2.0,fsr_G2GG_cNS_dn fsr:G2GG:cNS=-2.0,fsr_G2GG_cNS_up fsr:G2GG:cNS=2.0,fsr_G2QQ_cNS_dn fsr:G2QQ:cNS=-2.0,fsr_G2QQ_cNS_up fsr:G2QQ:cNS=2.0,fsr_Q2QG_cNS_dn fsr:Q2QG:cNS=-2.0,fsr_Q2QG_cNS_up fsr:Q2QG:cNS=2.0,fsr_X2XG_cNS_dn fsr:X2XG:cNS=-2.0,fsr_X2XG_cNS_up fsr:X2XG:cNS=2.0,isr_G2GG_muR_dn isr:G2GG:muRfac=0.5,isr_G2GG_muR_up isr:G2GG:muRfac=2.0,isr_G2QQ_muR_dn isr:G2QQ:muRfac=0.5,isr_G2QQ_muR_up isr:G2QQ:muRfac=2.0,isr_Q2QG_muR_dn isr:Q2QG:muRfac=0.5,isr_Q2QG_muR_up isr:Q2QG:muRfac=2.0,isr_X2XG_muR_dn isr:X2XG:muRfac=0.5,isr_X2XG_muR_up isr:X2XG:muRfac=2.0,isr_G2GG_cNS_dn isr:G2GG:cNS=-2.0,isr_G2GG_cNS_up isr:G2GG:cNS=2.0,isr_G2QQ_cNS_dn isr:G2QQ:cNS=-2.0,isr_G2QQ_cNS_up isr:G2QQ:cNS=2.0,isr_Q2QG_cNS_dn isr:Q2QG:cNS=-2.0,isr_Q2QG_cNS_up isr:Q2QG:cNS=2.0,isr_X2XG_cNS_dn isr:X2XG:cNS=-2.0,isr_X2XG_cNS_up isr:X2XG:cNS=2.0}','UncertaintyBands:nFlavQ = 4','UncertaintyBands:MPIshowers = on','UncertaintyBands:overSampleFSR = 10.0','UncertaintyBands:overSampleISR = 10.0','UncertaintyBands:FSRpTmin2Fac = 20','UncertaintyBands:ISRpTmin2Fac = 1'}
  })
 }

So the module which is creating the GenEventInfoProduct is Pythia8HadronizerFilter.

[Dr15Jones]

The weights for GenEventInfoProduct seem to be filled by Pythia8HadronizerFilter here

cmssw/GeneratorInterface/Pythia8Interface/plugins/Pythia8Hadronizer.cc

Lines 678 to 733 in 982c595

	if (mergeweight != 1.) {
	event()->weights()[0] *= mergeweight;
	}
	if (fEmissionVetoHook.get()) {
	nISRveto += fEmissionVetoHook->getNISRveto();
	nFSRveto += fEmissionVetoHook->getNFSRveto();
	}
	//fill additional weights for systematic uncertainties
	if (fMasterGen->info.getWeightsDetailedSize() > 0) {
	for (const string &key : fMasterGen->info.initrwgt->weightsKeys) {
	double wgt = (*fMasterGen->info.weights_detailed)[key];
	event()->weights().push_back(wgt);
	}
	} else if (fMasterGen->info.getWeightsCompressedSize() > 0) {
	for (unsigned int i = 0; i < fMasterGen->info.getWeightsCompressedSize(); i++) {
	double wgt = fMasterGen->info.getWeightsCompressedValue(i);
	event()->weights().push_back(wgt);
	}
	}
	// fill shower weights
	// http://home.thep.lu.se/~torbjorn/pythia82html/Variations.html
	if (fMasterGen->info.nWeights() > 1) {
	for (int i = 0; i < fMasterGen->info.nWeights(); ++i) {
	double wgt = fMasterGen->info.weight(i);
	event()->weights().push_back(wgt);
	}
	}
	// VINCIA shower weights
	// http://vincia.hepforge.org/current/share/Vincia/htmldoc/VinciaUncertainties.html
	if (fvincia.get()) {
	event()->weights()[0] *= fvincia->weight(0);
	for (int iVar = 1; iVar < fvincia->nWeights(); iVar++) {
	event()->weights().push_back(fvincia->weight(iVar));
	}
	}
	// Retrieve Dire shower weights
	if (fDire.get()) {
	fDire->weightsPtr->calcWeight(0.);
	fDire->weightsPtr->reset();
	//Make sure the base weight comes first
	event()->weights()[0] *= fDire->weightsPtr->getShowerWeight("base");
	map<string, double>::iterator it;
	for (it = fDire->weightsPtr->getShowerWeights()->begin(); it != fDire->weightsPtr->getShowerWeights()->end();
	it++) {
	if (it->first == "base")
	continue;
	event()->weights().push_back(it->second);
	}
	}

[Dr15Jones]

The GenLumiInfoHeader which is generated by Pythia8HadronizerFilter contains a method called weightNames(). If I do

LuminosityBlocks->Scan("GenLumiInfoHeader_generator__GEN.obj.weightNames()")

Then I get the results

***********************************
*    Row   * Instance * GenLumiIn *
***********************************
*        0 *        0 *   nominal *
*        0 *        1 *  Baseline *
*        0 *        2 * fsr:murfa *
*        0 *        3 * fsr:murfa *
*        0 *        4 * fsr:murfa *
*        0 *        5 * fsr:murfa *
*        0 *        6 * fsr:murfa *
*        0 *        7 * fsr:murfa *
*        0 *        8 * fsr:g2gg: *
*        0 *        9 * fsr:g2gg: *
*        0 *       10 * fsr:g2qq: *
*        0 *       11 * fsr:g2qq: *
*        0 *       12 * fsr:q2qg: *
*        0 *       13 * fsr:q2qg: *
*        0 *       14 * fsr:x2xg: *
*        0 *       15 * fsr:x2xg: *
*        0 *       16 * fsr:g2gg: *
*        0 *       17 * fsr:g2gg: *
*        0 *       18 * fsr:g2qq: *
*        0 *       19 * fsr:g2qq: *
*        0 *       20 * fsr:q2qg: *
*        0 *       21 * fsr:q2qg: *
*        0 *       22 * fsr:x2xg: *
*        0 *       23 * fsr:x2xg: *
*        0 *       24 * isr:murfa *
*        0 *       25 * isr:murfa *
*        0 *       26 * isr:murfa *
*        0 *       27 * isr:murfa *
*        0 *       28 * isr:murfa *
*        0 *       29 * isr:murfa *
*        0 *       30 * isr:g2gg: *
*        0 *       31 * isr:g2gg: *
*        0 *       32 * isr:g2qq: *
*        0 *       33 * isr:g2qq: *
*        0 *       34 * isr:q2qg: *
*        0 *       35 * isr:q2qg: *
*        0 *       36 * isr:x2xg: *
*        0 *       37 * isr:x2xg: *
*        0 *       38 * isr:g2gg: *
*        0 *       39 * isr:g2gg: *
*        0 *       40 * isr:g2qq: *
*        0 *       41 * isr:g2qq: *
*        0 *       42 * isr:q2qg: *
*        0 *       43 * isr:q2qg: *
*        0 *       44 * isr:x2xg: *
*        0 *       45 * isr:x2xg: *

*        1 *        0 *   nominal *
*        1 *        1 *  Baseline *
*        1 *        2 * fsr:murfa *
*        1 *        3 * fsr:murfa *
*        1 *        4 * fsr:murfa *
*        1 *        5 * fsr:murfa *
*        1 *        6 * fsr:murfa *
*        1 *        7 * fsr:murfa *
*        1 *        8 * fsr:g2gg: *
*        1 *        9 * fsr:g2gg: *
*        1 *       10 * fsr:g2qq: *
*        1 *       11 * fsr:g2qq: *
*        1 *       12 * fsr:q2qg: *
*        1 *       13 * fsr:q2qg: *
*        1 *       14 * fsr:x2xg: *
*        1 *       15 * fsr:x2xg: *
*        1 *       16 * fsr:g2gg: *
*        1 *       17 * fsr:g2gg: *
*        1 *       18 * fsr:g2qq: *
*        1 *       19 * fsr:g2qq: *
*        1 *       20 * fsr:q2qg: *
*        1 *       21 * fsr:q2qg: *
*        1 *       22 * fsr:x2xg: *
*        1 *       23 * fsr:x2xg: *
*        1 *       24 * isr:murfa *
*        1 *       25 * isr:murfa *
*        1 *       26 * isr:murfa *
*        1 *       27 * isr:murfa *
*        1 *       28 * isr:murfa *
*        1 *       29 * isr:murfa *
*        1 *       30 * isr:g2gg: *
*        1 *       31 * isr:g2gg: *
*        1 *       32 * isr:g2qq: *
*        1 *       33 * isr:g2qq: *
*        1 *       34 * isr:q2qg: *
*        1 *       35 * isr:q2qg: *
*        1 *       36 * isr:x2xg: *
*        1 *       37 * isr:x2xg: *
*        1 *       38 * isr:g2gg: *
*        1 *       39 * isr:g2gg: *
*        1 *       40 * isr:g2qq: *
*        1 *       41 * isr:g2qq: *
*        1 *       42 * isr:q2qg: *
*        1 *       43 * isr:q2qg: *
*        1 *       44 * isr:x2xg: *
*        1 *       45 * isr:x2xg: *
*        1 *       46 * isr:murfa *
*        1 *       47 * isr:murfa *
*        1 *       48 * isr:murfa *
*        1 *       49 * isr:murfa *
*        1 *       50 * isr:murfa *
*        1 *       51 * isr:murfa *
*        1 *       52 * isr:g2gg: *
*        1 *       53 * isr:g2gg: *
*        1 *       54 * isr:g2qq: *
*        1 *       55 * isr:g2qq: *
*        1 *       56 * isr:q2qg: *
*        1 *       57 * isr:q2qg: *
*        1 *       58 * isr:x2xg: *
*        1 *       59 * isr:x2xg: *
*        1 *       60 * isr:g2gg: *
*        1 *       61 * isr:g2gg: *
*        1 *       62 * isr:g2qq: *
*        1 *       63 * isr:g2qq: *
*        1 *       64 * isr:q2qg: *
*        1 *       65 * isr:q2qg: *
*        1 *       66 * isr:x2xg: *
*        1 *       67 * isr:x2xg: *

So the 2nd LuminosityBlock in the job has more weights (matching what we see in GenEventInfoProduct) with the extra ones appearing to start at index 47 and being a repeat of all the isr: ones.

[qliphy]

I tested locally
(1) HIG-RunIISummer19UL17wmLHEGEN-00356 (CMSSW_10_6_0_patch2)
and
(2) HIG-RunIIFall17wmLHEGS-00769 (CMSSW_9_3_6_patch1)
(3) HIG-RunIIFall18wmLHEGS-02121(CMSSW_10_2_15_patch2 )
with either
LuminosityBlocks->Scan("GenLumiInfoHeader_generator__SIM.obj.weightNames()")
or
LuminosityBlocks->Scan("GenLumiInfoHeader_generator__GEN.obj.weightNames()")

I could reproduce the issue with (1), i.e. increasing weights with LuminosityBlock

While for (2) and (3), there is no such issue. For (3), the weight number is always 46, as below:

root [1] LuminosityBlocks->Scan("GenLumiInfoHeader_generator__SIM.obj.weightNames()")

Row   * Instance * GenLumiIn *
     0 *        0 *   nominal *
     0 *        1 *  Baseline *
     0 *        2 *  isrRedHi *
     0 *        3 *  fsrRedHi *
      ......
     0 *       44 * isr_X2XG_ *
     0 *       45 * isr_X2XG_ *
     1 *        0 *   nominal *
     1 *        1 *  Baseline *
     1 *        2 *  isrRedHi *
     1 *        3 *  fsrRedHi *
     1 *        4 *  isrRedLo *
      .....
     1 *       45 * isr_X2XG_ *
     2 *        0 *   nominal *
     2 *        1 *  Baseline *
     2 *        2 *  isrRedHi *
     2 *        3 *  fsrRedHi *
     .....

[qliphy]

Tested further with EGM-RunIIWinter19PFCalib17wmLHEGS-00001, and found the issue appears already with 10_5_X. Note since 10_5_X, we have Pythia8 2.40

I also notice "fMasterGen->info.nWeights()" (a Pythia8 function to access uncertainty weights) is increasing with LuminosityBlock
https://github.com/cms-sw/cmssw/blob/CMSSW_10_6_X/GeneratorInterface/Pythia8Interface/plugins/Pythia8Hadronizer.cc#L957

Adding @mkirsano @alberto-sanchez @intrepid42 who should be able to check more above.

[qliphy]

Adding @smrenna

It seems to me possibly due to Pythia8 itself. As mentioned above, the issue appears since 10_5_X, i.e. from Pythia8.240

There are some differences on PS weights definitions between Pythia8.240 and 8.230:

https://github.com/cms-externals/pythia8/blob/cms/240/src/SimpleSpaceShower.cc#L3136
src/SimpleSpaceShower.cc: infoPtr->setNWeights( nWeights + nUncertaintyVariations );
src/SimpleTimeShower.cc: infoPtr->setNWeights( nUncertaintyVariations + 1 );

https://github.com/cms-externals/pythia8/blob/cms/230/src/SpaceShower.cc#L3040
src/SpaceShower.cc: infoPtr->setNWeights( nUncertaintyVariations + 1 );
src/TimeShower.cc: infoPtr->setNWeights( nUncertaintyVariations + 1 );

where the space shower (isr) part is different. For Pythia8.240, nWeights possibly gets increased at each initialization, that may explain why we see duplications from isr as mentioned above:
"So the 2nd LuminosityBlock in the job has more weights (matching what we see in GenEventInfoProduct) with the extra ones appearing to start at index 47 and being a repeat of all the isr: ones."

Note according to PS Weight fragment, there are totally 22 variations from isr, this may also explain the number 22 mentioned above by Marco:
"It was observed that the size of the vector often grows by 22 at a lumisection change, potentially up to very large numbers (~2000)"

So possibly we should change in
https://github.com/cms-externals/pythia8/blob/cms/240/src/SimpleSpaceShower.cc#L3136
from
src/SimpleSpaceShower.cc: infoPtr->setNWeights( nWeights + nUncertaintyVariations );
to
src/SimpleSpaceShower.cc: infoPtr->setNWeights( 1 + nUncertaintyVariations );

I will leave this for the Pythia author, @smrenna to comment here.

[agrohsje]

Dear @qliphy,
I found the same suspicious lines and tried to work Friday on a patch. However, the lines seem not a bug, at least the additional weights get initialized
infoPtr->setNWeights( nWeights + nUncertaintyVariations );
int newSize = infoPtr->nWeights();
for(int iWeight = nWeights; iWeight < newSize; ++iWeight) {
string uVarString = uniqueVars[iWeight - nWeights];
infoPtr->setWeightLabel(iWeight, uVarString);
So before committing my patch it would indeed be good if @smrenna could check.

[qliphy]

But as shown here:
https://github.com/cms-externals/pythia8/blob/cms/240/src/SimpleSpaceShower.cc#L3135
nWeights is defined by infoPtr->nWeights(), while nWeights() is defined here:
https://github.com/cms-externals/pythia8/blob/cms/240/include/Pythia8/Info.h#L179
and
https://github.com/cms-externals/pythia8/blob/cms/240/include/Pythia8/Info.h#L686

so it seems after each initialization, nWeights can get increased.

[smrenna]

Hi, I will definitely look into this tomorrow. Thanks. From: Qiang Li <[email protected]> Reply-To: cms-sw/cmssw <[email protected]> Date: Sunday, September 8, 2019 at 7:06 PM To: cms-sw/cmssw <[email protected]> Cc: Stephen Mrenna <[email protected]>, Mention <[email protected]> Subject: Re: [cms-sw/cmssw] GenEventInfoProduct weights size grows at lumisection change (#27918) But as shown here: https://github.com/cms-externals/pythia8/blob/cms/240/src/SimpleSpaceShower.cc#L3135<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cms-2Dexternals_pythia8_blob_cms_240_src_SimpleSpaceShower.cc-23L3135&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=Ug1yDCidB0GaBS4rmVb10yX4VLUmFOSk07ZAvWEDiNo&s=WWJRMBW9EvsJ4Q2lngZq44mEs7b57dKXm_tK_iAe1CE&e=> nWeights is defined by infoPtr->nWeights(), while nWeights() is defined here: https://github.com/cms-externals/pythia8/blob/cms/240/include/Pythia8/Info.h#L179<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cms-2Dexternals_pythia8_blob_cms_240_include_Pythia8_Info.h-23L179&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=Ug1yDCidB0GaBS4rmVb10yX4VLUmFOSk07ZAvWEDiNo&s=OD1yNzk1JNM-KOQJsizLp6ReQHNVJIrFPq6AxESFYos&e=> and https://github.com/cms-externals/pythia8/blob/cms/240/include/Pythia8/Info.h#L686<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cms-2Dexternals_pythia8_blob_cms_240_include_Pythia8_Info.h-23L686&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=Ug1yDCidB0GaBS4rmVb10yX4VLUmFOSk07ZAvWEDiNo&s=Cmx_8KSTV9rCkP6UWYIJ-SLKBF5vpldPjRjzL_9kWww&e=> so it seems after each initialization, nWeights can get increased. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cms-2Dsw_cmssw_issues_27918-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DABLSEJEFSFIVL4J7KAJP6WDQIWHO3A5CNFSM4ITDKNJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6F5SHI-23issuecomment-2D529258781&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=Ug1yDCidB0GaBS4rmVb10yX4VLUmFOSk07ZAvWEDiNo&s=9gv-2me8pQhpJ2D_JgTIMmu7yZj5le99dEhHuKsh22k&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABLSEJBBMD45WJG675U6ME3QIWHO3ANCNFSM4ITDKNJA&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=Ug1yDCidB0GaBS4rmVb10yX4VLUmFOSk07ZAvWEDiNo&s=h43W_TlcG2BNcZJ4Xty6y73YWkb0n3X7lPKmgFoHrlU&e=>.

[srimanob]

@smrenna @qliphy
Not sure that I understand the whole message. The increasing of the nWeights is reasonable (meaningful, usable) or it's not. I am trying to converge that this should be fix in the GEN side or more flexibility to handle this should be added to the NanoAOD. Thanks.

[agrohsje]

@srimanob
It is not reasonable. It comes from the interplay of CMS re-initialising P8 with every lumisection and the modification of P8 in version 8.240. Depending on Steve's feedback we should modify our P8 implementation.

[smrenna]

Most likely is that my collaborators don’t 100 percent understand how Pythia8 is used by CMS/ATLAS. This is on my list of problems to attack for today. Best, Steve From: agrohsje <[email protected]> Reply-To: cms-sw/cmssw <[email protected]> Date: Monday, September 9, 2019 at 6:05 AM To: cms-sw/cmssw <[email protected]> Cc: Stephen Mrenna <[email protected]>, Mention <[email protected]> Subject: Re: [cms-sw/cmssw] GenEventInfoProduct weights size grows at lumisection change (#27918) @srimanob<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_srimanob&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=FE9G341XY451pj0jhxgC4mx9lrFd0DvOwRe_hGKvRJM&s=ayvrI4O8YJ2ZfaykG9Z9YTuB1Mj0h22rz3bQDNZowbA&e=> It is not reasonable. It comes from the interplay of CMS re-initialising P8 with every lumisection and the modification of P8 in version 8.240. Depending on Steve's feedback we should modify our P8 implementation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cms-2Dsw_cmssw_issues_27918-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DABLSEJHRLJC5YPAKIPVNQ53QIYUZHA5CNFSM4ITDKNJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HEZ5Q-23issuecomment-2D529419510&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=FE9G341XY451pj0jhxgC4mx9lrFd0DvOwRe_hGKvRJM&s=sHTka8lY7YNO6F0DlCKS0b2gUl8yiu7apppae4f2nhQ&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABLSEJADOFMIYG3TFWONEF3QIYUZHANCNFSM4ITDKNJA&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=P6TR6eMSzDEOLYeqW0ECsQ&m=FE9G341XY451pj0jhxgC4mx9lrFd0DvOwRe_hGKvRJM&s=UOAIY2ZdqixD7EPhttvHK5JUCMXsLtrxopvO5Er_ogM&e=>.

[smrenna]

I modified an example file in the Pythia8 distribution, and I confirm that the number of weights change upon a second initialization.

However, I am not 100 percent sure this is what CMSSW does.
All I added was another call to init() half way through the run.

What I don’t know is this: what does CMSSW expect to happen?
Is all the configuration information presented again to Pythia?
Or, is Pythia expected to initialize using the information already stored internally? This is what I suspect.

[smrenna]

Please make the following change to Pythia.cc:
(only last line is changed. This should start around line 851)

// Initialize the random number generator.
if ( settings.flag("Random:setSeed") )
rndm.init( settings.mode("Random:seed") );

// Find which frame type to use.
info.addCounter(1);
frameType = mode("Beams:frameType");
info.setNWeights(1);
/////////////////
add this one line to not allow the number of weights to grow.

[smrenna]

Did a pull request in the cms externals branch:

cms-externals/pythia8#14

[agrohsje]

Thanks @smrenna. I tested the pull request and it is working fine. To summarize what I did.
I did a private 10_6_3 fixing P8 with the PR from Steve. Then I was running the parton shower on MG5 events where each event had a different lumi section: The PS weight vector does not change the size, it is always 46 as expected. Then I do the same but with official 10_6_3. I see that the weight vector increases as described above, i.e. the ISR weights get added for each re-init of P8.
In a second step I am comparing the weight values in all events. [1] shows that there is no difference in weights for the first event as expected (same random numbers, no re-init of P8 yet). [2] shows the result for the second event. The first 24 weights are identical. Then the next 22 weights in the right column (buggy sample) are wrong. Then, 24,25,.. (left) and 46,47,... (right) correspond again to each other and can be used. The same pattern appears in the next event, where 2*22 weights in the middle are buggy. So if we just use the first 24 and the last 22 weights of each event, we can also recycle the old buggy samples.
[1] http://www.desy.de/~agrohsje/hidden/p8_isrweights/first_event.png
[2] http://www.desy.de/~agrohsje/hidden/p8_isrweights/second_event.png

[fabiocos]

@agrohsje so your check seems to confirm on a few events that the fix is doing what expected without any apparent drawback. At this point I would suggest to integrate this version into a build to perform more extensive checks

[qliphy]

@fabiocos Yes it would be very nice to have a build and release with this fix included, as the other workaround (e.g. filtering unwanted weights) may still take time. Thanks!

[srimanob]

Can we consider that this issue is closed with the fix in cms-sw/cmsdist#5229 (backport to 10_6 cms-sw/cmsdist#5239) ?

Thanks you all.

[fabiocos]

@srimanob @peruzzim @agrohsje @qliphy as far as I understand the problem has gone, it would be good to have a final confirmation by Marco as well

[peruzzim]

If the GEN group has a MINIAOD test file generated with the new Pythia version, I can test NANOAOD on it, but this is something for them to sign off in the end

[qliphy]

Let me quote below what Alexander has checked in another email thread. Everything looks ok there.
For a further double check, you can run reval 1361.181 with 11_0_0_pre9 or 10_6_4.

Dear all,
as discussed I was running relval workflow 1361.181 in 11_0_0_pre9. I
reduced the number of events per lumi section to 2 and produced 10 events.
The weight names and values in the miniaod [1] look as expected. No
increase in size. 46 weights in each of the 5 lumi sections.
The workflow doesn't include nano-aod, but I assume this is not needed
based on my findings.
Cheers, Alexander for GEN.
[1] Events->Scan("GenEventInfoProduct_generator__SIM.obj.weights_") and
LuminosityBlocks->Scan("GenLumiInfoHeader_generator__SIM.obj.weightNames()")

[peruzzim]

Can we consider this item closed? If so GEN please sign

[qliphy]

+1

[cmsbuild]

This issue is fully signed and ready to be closed.