long-lived charged particles

[Wolfgang Waltenberger]

This may be seen as an interation to Ticket #87, I guess.
No answer is posted, so I ask this question again.
My question is about the treatment of heavy stable charged particles
in delphes. What does delphes currently do with such guys?
If it's not treated correctly (i.e. decayed according to their lifetimes), is such a feature on the delphes developers' todo list for the future?

Best

Wolfgang

[favereau]

Hi,

sorry we did not answer earlier.

For the moment, particles are decayed only in pythia and delphes does no such things. The question is more to decide how they should interact in the detector. As there is nothing explicit in the code, this is obviously not adressed properly.

However, the release of the modular version of delphes is due in less than a month and is thus in the final stages of developement. I suggest we use this ticket to discuss the details of a potential implementation of HSCPs.

Jerome

[Pavel Demin]

It would be interesting to have a file with this kind of events.

If these particles are final state particles (status == 1), then we could imagine the following steps:

1. generate the exact life time of this particle
2. generate the decay products
3. propagate this particle in the magnetic field to its decay point
4. propagate the decay products in the magnetic field to the calorimeters

I have no idea of the complexity of the steps 1 and 2. Is there a library that generates heavy stable charged particles decays (like TAUOLA for tau decays)?

I'm not sure whether the step 3 is really needed.

[Pavel Demin]

1. In our case the production vertex of the HSCP is the primary vertex.

So in the LHE file we have the HSCP originating from the primary vertex,
with the correct lifetime. So gamma and ctau are in the LHE file.

2. The decay products can be produced using e.g. pythia. Now in principle,

one could probably even produce the decay products beforehand and add it to the LHE file. But the LHE file it seems doesnt support the idea of a production vertex? So this would be a mess, right?

3. Right. In our case it's not needed because the HCSP is produced at the primary vertex.

4. Can I rephrase, just to be sure? Propagate the decay products to the decay vertex of the HCSP.

Thanks a lot for considering this,

Wolfgang

[Pavel Demin]

Dear Wolfgang,

Thanks for your comments.

First of all, I'll try to clarify what I consider by "propagation". If HSCP is produced at the primary vertex and have a finite tau then there should be a secondary vertex there the HSCP decays.

To define the position of the secondary vertex we should somehow propagate the HSCP from the primary to the secondary vertex. Probably, taking into account the magnetic field inside the detector.

I think that decaying this kind of particles inside Pythia is the cleanest solution.

Normally, the Pythia output can be registered in the STDHEP and HepMC formats. Both these formats have production vertexes associated with each particle.

[drigo]

Hi everybody,

I would have a question related to last comment.
If I wanted to analyze (and not to generate, in fact, I should have the position of this vertex) a process with a displaced vertex (and then two vertex) via Delphes, would it be able to do that?
A short time ago I read in the section "b-tagging" of the manual that "in the current version of Delphes (2010), the displacement of seconday vertices in not taken into account". is it still so?

Regarding HepMC format as pythia output, do You know how I can get it by Pythia8?

Thank You in advance.
All the best,
F.

[Pavel Demin]

Normally, each track has coordinates of its production vertex (Track.X, Track.Y, Track.Z). So, selecting Tracks with coordinates that are not (0,0,0), you'll have coordinates of all displaced vertexes. Do you think it would help your analysis?

Regarding HepMC format as pythia output, I've found the following instructions:

​http://home.thep.lu.se/~torbjorn/pythia81html/RIVETusage.html

[drigo]

Hi,

I think so!
can Delphes recognize particles coming from secondary vertices even if the second vertex is out of tracker? I mean, if I have some vertices in the tracker and some others out of it, will Delphes do the same analysis? How does it deal with this scenario?

Thank You very much!
Your help is very useful.
F.

[Pavel Demin]

Normally we have the following expression in the ParticlePropagator module (modules/ParticlePropagator.cc):

    // check that particle position is inside the cylinder
    if(TMath::Hypot(x, y) > fRadius || TMath::Abs(z) > fHalfLength)
    {
      continue;
    }

So, the particles originating from a vertex outside of the tracker (defined as a cylinder) are not recognized as tracks and are not propagated to the edge of the tracker volume. It means that these particles are completely ignored.

But the idea of Delphes is that nothing is carved in stone: it provides some default behavior that could be easily adapted by the users to their requirements.

So, if you have an idea of how the displaced vertex should be treated you can

• either try to adapt the ParticlePropagator module (and eventually other modules and classes) to your requirements
• or try to explain us your requirements and then we'll try to help you to modify Delphes

[drigo]

Hi,

first of all I thank you for Your reply.
To be honest I have to think how to treat my second vertex..
but most likely I will still need Your help.
Thank You in advance.
All the best.

F

[Archana]

Hello,

I have a relevant question. Say, I have a long lived charged particle (a chargino in my case), that decays somewhere in the tracker. I have the vertex information from Pythia, and I know the distance it travels before it decays. Does Delphes treat this particle as a track? I would add some cuts and analyze these tracks, and I couldn't figure if Delphes was storing these particles' info in tracks. Also, if I use the event visualizer, I dont see these long lived tracks, however, I do see the tracks from the chargino's decay products.

How can I get the pT, eta etc, of this long lived particle?

Thanks,
Archana