[Rivet] Pileup in Rivet

[Andy Buckley]

Nothing in H++ that I'm aware of, and I'm not sure how detailed the
pile-up modelling in Pythia is. You would certainly want a
parameterisation of z-component beam-spot spread, since most pile-up
reduction is done with track vertexing.

Proper detector-digitisation level pile-up simulation also includes the
other components, beam spot tilts, twist and lateral boost from beam
crossing angles, plus bunch structure! (or at least the ATLAS code will
when I find a moment to add some of those!) But the spatial distribution
in z is the only one I would worry about at MC level for semi-realistic
pile-up.

We do have a Rivet projection for primary vertex finding, but it's
hardly used since all single-interaction MC simulation happens at
(0,0,0)... you might need to do some work there, so get in touch if need
help.

Andy


On 13/10/10 11:36, Christian Roehr wrote:
> Hi James,
> 
> Thanks for the advice. Indeed I didn't know of this pile-up option in 
> Pythia. However, I guess there is no such option in Hw++. But anyway, 
> heading for a generator-independent solution is more reasonable probably. 
> I'll bear your suggestion in mind.
> 
> Cheers
> Christian
> 
> 
> 
> On Tue, 12 Oct 2010, James Monk wrote:
> 
>> Hi Christian,
>>
>> A HepMC pile-up compositor sounds like a useful tool.  Can I suggest the same pipe idiom used by rivet, but with two input pipes  - one providing the signal events and another providing the pile-up (which could come from a different generator entirely).
>>
>> Another possibility is that some generators have an option to produce pile-up on top of the signal I think.  I'm pretty sure Pythia has this feature (MSTP(131)), but I guess you're more interested in Herwig :)
>>
>> cheers,
>>
>> James
>>
>> On 8 Oct 2010, at 11:57, Christian Roehr wrote:
>>
>>> Hi Andy, hi all,
>>>
>>>
>>> Thanks for your mail, that's quite helpful anyway, even if Rivet does
>>> not do pileup. My guess is also that there shouldn't be much difficulty
>>> in realising that at HepMC level, in principle. However, maybe some
>>> tricks are necessary since HepMC stores any step of the event
>>> generation, as far as I am aware of. Thus it will be somewhat restricted
>>> to one event only.
>>>
>>> Thank you especially for offering your help on that. I'll be happy to
>>> come back to that at some point! For now I'm still dealing with the
>>> actual analysis first, preparing for studying pile-up based on that.
>>>
>>> Okay, I see, there are even further sources of contamination. In theory,
>>> everything is so easy... :) Thanks for the hint, I will have a chat on
>>> that with Jon Butterworth, who is my supervisor in this project.
>>>
>>>
>>> I will get in touch with you. Cheers!
>>>
>>> Christian
>>>
>>>
>>>
>>> On Wed, 6 Oct 2010, Andy Buckley wrote:
>>>
>>>> On 04/10/10 19:34, Christian Roehr wrote:
>>>>> Hallo Andy,
>>>>>
>>>>> I am wondering if a certain feature is present in Rivet and if not, how
>>>>> to deal with it.
>>>>>
>>>>> Currently I'm studying pileup effects, i.e. the presence of particles
>>>>> from additional minimum bias scatters within one bunch crossing (some 20
>>>>> or so). Effectively, this should be quite easy, since the additional
>>>>> scatterings are not colour-connected whatsoever to the tagged event.
>>>>>
>>>>> So, the straightforward way of analyzing that should be to simply add
>>>>> the fs particles of these minbias events to the final state of the
>>>>> original event. And analyze the resulting final state afterwards.
>>>>>
>>>>> Is there a possibility to do that in Rivet? I could not find anything
>>>>> like that (looked in the documentation and in the 1.2.1 code).
>>>>>
>>>>> Any help is very welcome, Andy. :)
>>>>
>>>> Hi Christian,
>>>>
>>>> Sorry, pile-up isn't something that Rivet simulates intrinsically and
>>>> isn't planned either. However, it should not be *too* hard to write a
>>>> little HepMC filter which aggregates min bias events and superimposes a
>>>> number of them on top of a signal event -- with semi-proper beam spot
>>>> and N_pileup sampling. We could help with putting that together if you
>>>> are interested.
>>>>
>>>> You should also make sure that the same-event pile-up is sufficient: I'm
>>>> involved in the detector simulation for ATLAS, and there is actually
>>>> quite a bit of complexity to handling the effect of bunch structure on
>>>> pile-up, as well as the more homogeneous backgrounds from thermalised
>>>> neutrons in the cavern (which will still be bouncing around 10 turns
>>>> after a min bias event) and beam halo. We actually do the
>>>> superimposition of these at the post-Geant4 stage, so I'm not actually
>>>> sure how good HepMC is at dealing with event structures like this...
>>>> shouldn't be a problem, I think, but I've said that before ;)
>>>>
>>>> Sorry to disappoint, but as I said if you'd be interested in trying to
>>>> make a pile-up builder at HepMC level then I'm sure we'll help with
>>>> building it and I would see no reason not to bundle it with Rivet to
>>>> help the next person to turn up with the same question!
>>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>> --
>>>> Dr Andy Buckley
>>>> SUPA Advanced Research Fellow
>>>> Particle Physics Experiment Group, University of Edinburgh
>>>>
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> http://www.hepforge.org/lists/listinfo/rivet
>>
>>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet
> 


-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh