About the setting of time_of_flight in run_card.dat

Dear Tim,

I’m actually investigating this mode and currently in communication with PY8/HW7/Delphes authors to clarify some point and see how consistently such information is handled. So here is my understanding of the (quite bad) situation so far

1) the LHEF convention has an entry related to displaced vertex. Here is the associate definition
invariant lifetime cτ (distance from production to decay) in mm
Combined with the directional information from the momentum, this is enough to determine vertex locations. Note that this gives the distance of travel for the particle from birth to death, in this particular event, and not its distance from the origin

2) MG5aMC returns the survival time in the rest-frame of the particle.
The parameter in the run_card allowed to defined a minimal survival lifetime. If the distance is below that value then MG5aMC will simply write 0.

3) Pythia8 seems to expect the invariant lifetime in the lab frame. (this still need to be clarify)
Also their tracing of production and decay vertices assumes no bending from magnetic or electrical fields, and no interactions with
any detector material. i.e. this is not always valid.

4) Herwig7 simply ignore that information in the LHEF. So the information would be lost. For internal generation/decay in HW7 , they handle the displaced vertex internally. I guess that the same limitation of PY8 applies for track bending and detector material.

5) Delphes simply use the vertex position provided in the HepMC (i.e. do not bend the track and/or try to simulation detector material interaction)

> If the decay length of this long-lived particle is about 10 cm, how to set the number for “time_of_flight " in run_card.dat to represent the decay length is about 10 cm for this new particle ?

Since MG provides this information in the rest-frame of the decaying particle it is not clear which time/distance it correspond to.
So the safer is to simply set that parameter to 0 such that you will have displaced vertex for all unstable particle.

Due to the situation described above,
I would say that the safest method so far is to do such generation without any care of displaced vertex up to the HepMC file.
When the HepMC file is generated, then I would parse it and correct the information in that file (and eventually bend the track at that stage if needed)
Before passing it trough detector simulation.

If your particle interact with the material of the detector, then I guess that you need to tweak the detector simulation to have that part handle correctly.

Cheers,

Olivier

> On Nov 10, 2016, at 03:32, Tim Lu <email address hidden> wrote:
>
> New question #403936 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/403936
>
> Hello !
> I face a problem about the setting of time_of_flight in run_card.dat.
> I have a new long-lived particle in the process when I run the MadGraph5_aMC@NLO. If the decay length of this long-lived particle is about 10 cm, how to set the number for "time_of_flight " in run_card.dat to represent the decay length is about 10 cm for this new particle ?
>
> Thank you in advance !
>
> Best,
> Tim
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,

Rectification, pythia8, expect this time in the rest frame of the particle.
So the information provided by MG is correctly handle by pythia8.

Cheers,

Olivier

> On Nov 10, 2016, at 11:33, Olivier Mattelaer <email address hidden> wrote:
>
> Question #403936 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/403936
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Dear Tim,
>
> I’m actually investigating this mode and currently in communication with
> PY8/HW7/Delphes authors to clarify some point and see how consistently
> such information is handled. So here is my understanding of the (quite
> bad) situation so far
>
> 1) the LHEF convention has an entry related to displaced vertex. Here is the associate definition
> invariant lifetime cτ (distance from production to decay) in mm
> Combined with the directional information from the momentum, this is enough to determine vertex locations. Note that this gives the distance of travel for the particle from birth to death, in this particular event, and not its distance from the origin
>
> 2) MG5aMC returns the survival time in the rest-frame of the particle.
> The parameter in the run_card allowed to defined a minimal survival lifetime. If the distance is below that value then MG5aMC will simply write 0.
>
> 3) Pythia8 seems to expect the invariant lifetime in the lab frame. (this still need to be clarify)
> Also their tracing of production and decay vertices assumes no bending from magnetic or electrical fields, and no interactions with
> any detector material. i.e. this is not always valid.
>
> 4) Herwig7 simply ignore that information in the LHEF. So the
> information would be lost. For internal generation/decay in HW7 , they
> handle the displaced vertex internally. I guess that the same limitation
> of PY8 applies for track bending and detector material.
>
> 5) Delphes simply use the vertex position provided in the HepMC (i.e. do
> not bend the track and/or try to simulation detector material
> interaction)
>
>
>> If the decay length of this long-lived particle is about 10 cm, how to set the number for “time_of_flight " in run_card.dat to represent the decay length is about 10 cm for this new particle ?
>
> Since MG provides this information in the rest-frame of the decaying particle it is not clear which time/distance it correspond to.
> So the safer is to simply set that parameter to 0 such that you will have displaced vertex for all unstable particle.
>
> Due to the situation described above,
> I would say that the safest method so far is to do such generation without any care of displaced vertex up to the HepMC file.
> When the HepMC file is generated, then I would parse it and correct the information in that file (and eventually bend the track at that stage if needed)
> Before passing it trough detector simulation.
>
> If your particle interact with the material of the detector, then I
> guess that you need to tweak the detector simulation to have that part
> handle correctly.
>
>
> Cheers,
>
> Olivier
>
>
>> On Nov 10, 2016, at 03:32, Tim Lu <email address hidden> wrote:
>>
>> New question #403936 on MadGraph5_aMC@NLO:
>> https://answers.launchpad.net/mg5amcnlo/+question/403936
>>
>> Hello !
>> I face a problem about the setting of time_of_flight in run_card.dat.
>> I have a new long-lived particle in the process when I run the MadGraph5_aMC@NLO. If the decay length of this long-lived particle is about 10 cm, how to set the number for "time_of_flight " in run_card.dat to represent the decay length is about 10 cm for this new particle ?
>>
>> Thank you in advance !
>>
>> Best,
>> Tim
>>
>> --
>> You received this question notification because you are an answer
>> contact for MadGraph5_aMC@NLO.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Thanks Olivier Mattelaer, that solved my question.

Dear Olivier,

Sorry to bother you again.
When I set the parameter of “time_of_flight " to be 0 in run_card, it will appear the following error during the running :

KeyError : 'id (21,) is not in decay'

My process is
p p > zp j j, zp > e+ e-
where zp is a long-lived particle.

I try some different methods, but this error still apperars...

Best,
Tim

Hi Tim,

This means that your param_card does not follow correctly the convention.
In particular, looks like that you miss the information on the width of the gluon.

Cheers,

Olivier

> On Nov 17, 2016, at 02:53, Tim Lu <email address hidden> wrote:
>
> Question #403936 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/403936
>
> Status: Solved => Open
>
> Tim Lu is still having a problem:
> Dear Olivier,
>
> Sorry to bother you again.
> When I set the parameter of “time_of_flight " to be 0 in run_card, it will appear the following error during the running :
>
> KeyError : 'id (21,) is not in decay'
>
> My process is
> p p > zp j j, zp > e+ e-
> where zp is a long-lived particle.
>
> I try some different methods, but this error still apperars...
>
> Best,
> Tim
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.