Changes needed for SUSY parameter scans #13530
Conversation
…internal state of the random engine and not the current seed
… avoid potential issues with slha double initialization
… LHE generation at beginLuminosityBlock in the hadronizers
…duced in beginLuminosityBlockProduce, plus fix for gridpack randomization
|
The changes to particle gun are due to a cleanup of the inheritance structure. This made it painful to extend the hadronizer interface, because additional functions would need to be explicitly implemented for the particle guns. So the inheritance was rearranged in the pythia8 interface such that all hadronizers now inherit from BaseHadronizer (at least indirectly) |
|
+1 for 06c3c39
|
|
The tests are being triggered in jenkins. |
|
(so the functions which were removed from the guns are no longer needed because they are already implemented by some of the base classes) |
|
+1 |
|
Anything still holding this up? Analysis signature is needed for miniaod event content change? |
|
just time for me to look at it… sorry for the holdup
|
|
@Dr15Jones @wddgit - were you ok with the random number implementation in the end? |
|
This looks OK to me now. I cannot see any problems. |
|
+1
|
Changes needed for SUSY parameter scans
Adds the possibility to provide a list of configurations to Pythia8 and randomly select from the list of possible configurations at beginLuminosityBlock time.
This allows to produce a parameter scan in a single monte carlo request/dataset for whatever can be varied at the pythia level. This is targeted initially for SUSY fastsim signal production in 80x where the parameter scan is over the SUSY decay chain defined by the SLHA header, which can be inlined as part of the pythia8 configuration.
Since the changes are non-trivial agreed to put it in 81x first and backport afterwards.
This is the (near) final implementation of the proposal discussed in https://indico.cern.ch/event/487292/contribution/15/attachments/1218978/1781280/susyscan-Jan28-2016.pdf
Doing this safely requires a more complete re-initizalization of pythia at lumi section boundaries (pointer to main program and those related to userhooks are completely deleted and recreated rather than just calling init() again)
I've tested that this does not leak memory at any observable rate over several thousand lumi sections.
The inheritance of the Pythia8 interfaces was also slightly reorganized so that everything really inherits from BaseHadronizer now. (previously some of the particle guns did not, which made it more painful to extend the hadronizer api)
The DataFormats changes are needed to store in the event information on which config has been chosen as well as the LHE-related info discussed below. A new GenLumiInfoHeader class is created so that it can be filled in beginLuminosityBlock and accessed within a lumi section if needed. (existing GenLumiInfoProduct needs information only available at the end of the lumi section)
There is an important new functionality on top of this to allow accessing a gridpack and producing LHE events within the BaseHadronizer at beginLuminosityBlock time instead of in the ExternalLHEProducer. In this case gridpacks can also be randomly selected together with the pythia configuration. LHE events produced in this way bypass completely the existing LHE machinery in CMSSW and use directly the Pythia8 LHE parser. In this case the related information on additional weights must be stored in the GenEventInfoProduct and new GenLumiInfoHeader.
Note that due to some issues in the Pythia8 LHE parser the information related to which weight is which in the GenEventInfoProduct is currently incomplete. This will require some further patches and/or updates to pythia8 to fully resolve, but this pull request is already at least functional without it, so we should get it into the release and tested.
This pull request replaces #13433