[Rivet] Rivet: Accessing intermediate particles

[Andy Buckley]

Hi David,

Sorry that we've not found an answer before your deadline this time -- I
hope this wasn't a one-off opportunity and the whole thing now has to be
abandoned? Not even ATLAS is that crazy, usually, but this week is a bit
special...

Anyway, thanks for the code: very helpful. It looks correct to me. The
alternative (and more fundamental) way to try would be explicitly asking
the production vertex for its particles_in iterators and using those.
There's nothing that says a generator can't write an event with a single
interaction vertex that has two beams going in an a load of stable
particles coming out, but I've never seen it before: you could try using
mcviz or similar to plot the event structure if this contiues to be
troublesome.

Note that this is really a pure HepMC/Sherpa issue rather than a Rivet
one... unless I messed up when writing that particles(GevVertex*,
relation) function. So yes, there are *always* deadlines, but sometimes
the short cut route doesn't even exist and it'll just take longer. I
don't think that *should* be the case here, but then I've never tried to
do this on a Sherpa event. Good luck -- and please let us know if
there's anything else we can do to help.

Cheers,
Andy


On 30/06/12 19:51, David Hall wrote:
> Hi Andy,
> 
> Its possible that they are not the incoming protons. I just checked the
> PDG code for the parents and it returned 2212. I can do this additional
> check though to see if they are incoming protons.
> 
> I am finding the electrons in the following way (sorry for the code, but
> I thought it was the simplest way to explain):
> 
> IdentifiedFinalState elecs(-100.0, 100.0, 0.0*GeV);
> elecs.acceptIdPair(ELECTRON);
> addProjection(elecs, "elecs");
> 
> ...
> 
> ParticleVector elecs;
> foreach(const Particle& elec, applyProjection<FinalState>(event,
> "elecs").particlesByPt()){
>     GenVertex* prodVtx = elec.genParticle().production_vertex();
>     if (prodVtx == 0) continue;
>     bool isFromDecay = false;
>     foreach (const GenParticle* parent, particles(prodVtx,
> HepMC::parents)){
>           if (parent->status() == 2)
>                 isFromDecay = true;
>     }
>     if (!isFromDecay)
>           elecs.push_back(elec);
> }
> 
> I'd still be interested to hear how to do this, but I believe it is too
> late for my deadline.
> 
> Thanks,
> David
> 
> 
> On 30/06/12 20:07, Andy Buckley wrote:
>> On 30/06/12 18:43, David Hall wrote:
>>> Hi Hendrik,
>>>
>>> When I look at the parents of the electrons, it just gives me the
>>> incoming protons. It does this for >=2 electrons, so not just for
>>> electrons from the hard scatter. So it seems I can't differentiate
>>> between electrons this way.
>> Ok, so Sherpa says that the parents of *all* electrons are the protons,
>> and these have status 2? That doesn't sound right -- beam particles
>> should have status 4, and even in Sherpa there should be hadronic decay
>> chains in the event record: checking whether the parent satisfies the
>> PID::isHadron(pid) function would be another physically valid check that
>> you can't do in real experiments.
>>
>> How are you accessing the lepton parents in HepMC? There are several
>> ways, one of which would really list *all* the upstream ancestor
>> particles in the event record, starting with the beams... but that
>> wouldn't be the right one to use.
>>
>>> I agree that in an ideal world we can just treat everything exactly as
>>> we would in data. Unfortunately, due to time constraints and deadlines
>>> we often need a quick way to do things, so we need to be able to do
>>> truth-level studies like this relatively quickly.
>> That's not a good argument in general -- it doesn't take *that* long to
>> write a truth analysis (certainly not compared to doing the data
>> analysis part) and the "quick and obvious" way is often limited in
>> accuracy and physical meaning in ways that are not immediately
>> appreciated, especially if, e.g. your gamma* was really an admixture of
>> gamma* and Z0 and you wanted to distinguish those components. But
>> checking whether a particle was produced in a hadronic decay or a
>> pre-hadronisation part of the event should be possible and reliable, so
>> I hope this issue with Sherpa is just a technical one...
>>
>> Cheers,
>> Andy
>>
>>
>>> On Sat 30 Jun 2012 19:25:52 CEST, Hendrik Hoeth wrote:
>>>> Hi David,
>>>>
>>>> Thus spake David Hall (David.Hall at physics.ox.ac.uk):
>>>>
>>>>> Unfortunately, when I check the status of each parent of the electron
>>>>> in an event, I find that they are _all_ status 2. This suggests that
>>>>> all the electrons are from decays, but I know this shouldn't be the
>>>>> case. Two should be from the hard scatter. Is it possible this is
>>>>> specific to Sherpa?
>>>> Well, technically even in the hard scatter the electrons are decay
>>>> products of something. Though luck, eh? I mean ...
>>>>
>>>>>>> I understand the philosophy behind Rivet not providing access to the
>>>>>>> intermediate particles, but I believe that looking for the particles
>>>>>> >from the hard process in this way is not _so_ bad. :-)
>>>> ... nature doesn't mark the particles from the hard process, either. So
>>>> the best thing is to resort to physically meaningful observables,
>>>> similar to what you do in the experiment.
>>>>
>>>> Cheers,
>>>>
>>>>       Hendrik
>>>>
>>>> PS: I assume you know you can walk through the whole HepMC tree in the
>>>> same way you asked for the electrons' parents. That's all the generator
>>>> supplies.
>>>>
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> http://www.hepforge.org/lists/listinfo/rivet
>>>
>>
> 
> 
> 


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

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.