Production-decay chain in CalcHEP

Asked by Matt

Dear CalcHEP team,

I am dealing with a model with heavy quarks interacting with both gauge and contact interactions (implemented with an auxiliary vector boson) with standard model particles. When I try to compute the contribution of one of these quarks, let's say Ups, for the cross section of the process p,p->e+,ve,jet,jet I usually use the following syntax:
...
Process: p,p->Ups,jet
Decay: Ups->e+,ve,jet
...

So the question is: is CalcHEP computing the cross-section as "production_cross_section*Branching_ratio" with this syntax?
Note that we could have for example Width(Ups->e+,ve,jet)~21 GeV, with Mass(Ups)=5000 GeV.
Performing a quick check by computing separately (with CalcHEP) production cross section and BR it seems that their product is different from the cross section obtained with the syntax written above.

Cheers,
Matt.

Question information

Language:
English Edit question
Status:
Expired
For:
CalcHEP Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Alexander Pukhov (pukhov) said :
#1

Cross section included in Les Houches Event file should be the same
as you wrote.
Let me know if you see something else. But other cross sections written
in html file present intermediate steps of calculation and don't
include branching factor.

Best
    Alexander Pukhov

On 12/19/2017 01:12 PM, Matt wrote:
> New question #661970 on CalcHEP:
> https://answers.launchpad.net/calchep/+question/661970
>
> Dear CalcHEP team,
>
> I am dealing with a model with heavy quarks interacting with both gauge and contact interactions (implemented with an auxiliary vector boson) with standard model particles. When I try to compute the contribution of one of these quarks, let's say Ups, for the cross section of the process p,p->e+,ve,jet,jet I usually use the following syntax:
> ...
> Process: p,p->Ups,jet
> Decay: Ups->e+,ve,jet
> ...
>
> So the question is: is CalcHEP computing the cross-section as "production_cross_section*Branching_ratio" with this syntax?
> Note that we could have for example Width(Ups->e+,ve,jet)~21 GeV, with Mass(Ups)=5000 GeV.
> Performing a quick check by computing separately (with CalcHEP) production cross section and BR it seems that their product is different from the cross section obtained with the syntax written above.
>
> Cheers,
> Matt.
>

Revision history for this message
Matt (elvin.j) said :
#2

Thanks for the clarification.
Anyway I am still wondering if CalcHEP takes into account all 3-body decays when computing the Branching factor...
Indeed in my model with contact interactions mediated by a heavy auxiliary particle the major contribution is expected to be given by these kind of processes.
This question arises since I have tried to check again the Branching fraction by computing the different 3-body decay channels of the particle in exam
...
   Decay: Ups->e+,ve,jet
   Decay: Ups->mu+,vm,jet
   Decay: Ups->ta+,vt,jet
   Decay: Ups->jet,jet,jet
...
but it seems that the BR I have derived is different from the one obtained by simply dividing the cross section of the full process (p,p->Ups,jet->e+,ve,jet,jet) for the production cross section (p,p->Ups,jet) - with the values of the cross sections found in the LHE files.

I hope I was clear enough, thank you!

Best,

Matt

Revision history for this message
Alexander Belyaev (alexander.belyaev) said :
#3

Dear Matt,

when you request
Process: p,p->Ups,jet
Decay: Ups->e+,ve,jet

CalcHEP indeed evaluates production cross section x Br

The Br is evaluated as follows:
1. CalcHEP checks if 1->2 decay is opened, if it is, then it finds the total width as the sum of the
all 1->2 procsesses
2. If 1->2 is closed, CalcHEP evaluates 1->3 etc.
3. One the total decay width is evaluated , CalcHEP will evaluate
the Ups->e+,ve,jet partial decay width and respective branching which will be used to find the final result.

Revision history for this message
Matt (elvin.j) said :
#4

Dear Alexander,

it seems that the syntax I am using for the process doesn’t meet my needs...
Since the 1->2 decay is opened in my case (Ups can decay in W^+ and an up-quark), CalcHEP actually computes the BR as:

 Width(Ups->e+,ve,jet)/Width(Ups->W+,jet)

But the point is that in this way the four-fermion contact interactions are not considered at all in the BR!

So could you please suggest me another syntax (if any!) to consider only the Ups contribution to the signal (pp->e+,ve,jet,jet) - which otherwise would be dominated by SM processes - &/or any way to force CalcHEP to consider both 1->2 and 1->3 decays?

Cheers,
Matt

> On 30 Dec 2017, at 11:22, Alexander Belyaev <email address hidden> wrote:
>
> Your question #661970 on CalcHEP changed:
> https://answers.launchpad.net/calchep/+question/661970
>
> Status: Open => Answered
>
> Alexander Belyaev proposed the following answer:
> Dear Matt,
>
> when you request
> Process: p,p->Ups,jet
> Decay: Ups->e+,ve,jet
>
> CalcHEP indeed evaluates production cross section x Br
>
> The Br is evaluated as follows:
> 1. CalcHEP checks if 1->2 decay is opened, if it is, then it finds the total width as the sum of the
> all 1->2 procsesses
> 2. If 1->2 is closed, CalcHEP evaluates 1->3 etc.
> 3. One the total decay width is evaluated , CalcHEP will evaluate
> the Ups->e+,ve,jet partial decay width and respective branching which will be used to find the final result.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/calchep/+question/661970/+confirm?answer_id=2
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/calchep/+question/661970
>
> You received this question notification because you asked the question.

Revision history for this message
Alexander Belyaev (alexander.belyaev) said :
#5

Dear Matt,

if Gamma(1->3) is comparable with Gamma(1->2), then the situation is tricky and we need to think how to solve the problem. Eventually we will.

Could you tell me please roughly the ratio of these two or send me the model together with the batch file to
<email address hidden>
?

Revision history for this message
Matt (elvin.j) said :
#7

Dear Alexander,

Thank you for the answer.
In most of the points of the parameters space I’ve found a ratio
G(1->3)/G(1->2) ~ 14

Sorry for being late in answering about it.

Best,

Matt

Il 17 Gen 2018 10:08, "Launchpad Janitor" <
<email address hidden>> ha scritto:

> Your question #661970 on CalcHEP changed:
> https://answers.launchpad.net/calchep/+question/661970
>
> Status: Needs information => Expired
>
> Launchpad Janitor expired the question:
> This question was expired because it remained in the 'Needs information'
> state without activity for the last 15 days.
>
> --
> If you're still having this problem, you can reopen your question either
> by replying to this email or by going to the following page and
> entering more information about your problem:
> https://answers.launchpad.net/calchep/+question/661970
>
> You received this question notification because you asked the question.
>

Revision history for this message
Alexander Pukhov (pukhov) said :
#8

Does Ups have 1->2 decay mode?

  If Ups has 1->2 decay modes, then it will work as you expect but total
width of Ups will be  calculated via  1->2 decays. So, if

width Ups(1->2) >> width Ups(1-> e+,ve,jet) then result presented by
CalcHEP will be correct. Otherwise CalcHEP loses factor

width(1->2)/(width(1->2) +width(1->3))

Let us know, Is it namely the problem that you meet?

Best
     Alexander Pukhov

On 12/19/2017 11:12 AM, Matt wrote:
> New question #661970 on CalcHEP:
> https://answers.launchpad.net/calchep/+question/661970
>
> Dear CalcHEP team,
>
> I am dealing with a model with heavy quarks interacting with both gauge and contact interactions (implemented with an auxiliary vector boson) with standard model particles. When I try to compute the contribution of one of these quarks, let's say Ups, for the cross section of the process p,p->e+,ve,jet,jet I usually use the following syntax:
> ...
> Process: p,p->Ups,jet
> Decay: Ups->e+,ve,jet
> ...
>
> So the question is: is CalcHEP computing the cross-section as "production_cross_section*Branching_ratio" with this syntax?
> Note that we could have for example Width(Ups->e+,ve,jet)~21 GeV, with Mass(Ups)=5000 GeV.
> Performing a quick check by computing separately (with CalcHEP) production cross section and BR it seems that their product is different from the cross section obtained with the syntax written above.
>
> Cheers,
> Matt.
>

Revision history for this message
Matt (elvin.j) said :
#9

Hi,

Ups has both 1->2 and 1->3 decays (and they have also comparable widths), so this is exactly my problem!
Is there a work around for this?

Thanks a lot.
Best,

Matt

> On 20 Jan 2018, at 14:43, Alexander Pukhov <email address hidden> wrote:
>
> Your question #661970 on CalcHEP changed:
> https://answers.launchpad.net/calchep/+question/661970
>
> Status: Open => Answered
>
> Alexander Pukhov proposed the following answer:
> Does Ups have 1->2 decay mode?
>
> If Ups has 1->2 decay modes, then it will work as you expect but total
> width of Ups will be calculated via 1->2 decays. So, if
>
> width Ups(1->2) >> width Ups(1-> e+,ve,jet) then result presented by
> CalcHEP will be correct. Otherwise CalcHEP loses factor
>
> width(1->2)/(width(1->2) +width(1->3))
>
>
> Let us know, Is it namely the problem that you meet?
>
> Best
> Alexander Pukhov
>
>
> On 12/19/2017 11:12 AM, Matt wrote:
>> New question #661970 on CalcHEP:
>> https://answers.launchpad.net/calchep/+question/661970
>>
>> Dear CalcHEP team,
>>
>> I am dealing with a model with heavy quarks interacting with both gauge and contact interactions (implemented with an auxiliary vector boson) with standard model particles. When I try to compute the contribution of one of these quarks, let's say Ups, for the cross section of the process p,p->e+,ve,jet,jet I usually use the following syntax:
>> ...
>> Process: p,p->Ups,jet
>> Decay: Ups->e+,ve,jet
>> ...
>>
>> So the question is: is CalcHEP computing the cross-section as "production_cross_section*Branching_ratio" with this syntax?
>> Note that we could have for example Width(Ups->e+,ve,jet)~21 GeV, with Mass(Ups)=5000 GeV.
>> Performing a quick check by computing separately (with CalcHEP) production cross section and BR it seems that their product is different from the cross section obtained with the syntax written above.
>>
>> Cheers,
>> Matt.
>>
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/calchep/+question/661970/+confirm?answer_id=7
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/calchep/+question/661970
>
> You received this question notification because you asked the question.

Revision history for this message
Alexander Pukhov (pukhov) said :
#10

OK, Tomorrow  I'll check a possibility to add 1->3 width to 1_2 one if
the user adds 1->3 events. I hope it will be easy to realize.

I'll write you tomorrow about success.

Possible problem from the user side.  1->3 should not be realized via
subdecays.

May  be there are several 1->3 decay modes  which we have to add.

I don't know how to add 1->3 and 1->4 automatically.  Here there are a
lot of problems with double counting.

Sometimes, ( Hioggs -> W+,W-)  1->3  result is very far form correct 1->4.

Best

    Alexander Pukhov

On 01/21/2018 12:23 PM, Matt wrote:
> Question #661970 on CalcHEP changed:
> https://answers.launchpad.net/calchep/+question/661970
>
> Status: Answered => Open
>
> Matt is still having a problem:
> Hi,
>
> Ups has both 1->2 and 1->3 decays (and they have also comparable widths), so this is exactly my problem!
> Is there a work around for this?
>
> Thanks a lot.
> Best,
>
> Matt
>
>> On 20 Jan 2018, at 14:43, Alexander Pukhov <email address hidden> wrote:
>>
>> Your question #661970 on CalcHEP changed:
>> https://answers.launchpad.net/calchep/+question/661970
>>
>> Status: Open => Answered
>>
>> Alexander Pukhov proposed the following answer:
>> Does Ups have 1->2 decay mode?
>>
>> If Ups has 1->2 decay modes, then it will work as you expect but total
>> width of Ups will be calculated via 1->2 decays. So, if
>>
>> width Ups(1->2) >> width Ups(1-> e+,ve,jet) then result presented by
>> CalcHEP will be correct. Otherwise CalcHEP loses factor
>>
>> width(1->2)/(width(1->2) +width(1->3))
>>
>>
>> Let us know, Is it namely the problem that you meet?
>>
>> Best
>> Alexander Pukhov
>>
>>
>> On 12/19/2017 11:12 AM, Matt wrote:
>>> New question #661970 on CalcHEP:
>>> https://answers.launchpad.net/calchep/+question/661970
>>>
>>> Dear CalcHEP team,
>>>
>>> I am dealing with a model with heavy quarks interacting with both gauge and contact interactions (implemented with an auxiliary vector boson) with standard model particles. When I try to compute the contribution of one of these quarks, let's say Ups, for the cross section of the process p,p->e+,ve,jet,jet I usually use the following syntax:
>>> ...
>>> Process: p,p->Ups,jet
>>> Decay: Ups->e+,ve,jet
>>> ...
>>>
>>> So the question is: is CalcHEP computing the cross-section as "production_cross_section*Branching_ratio" with this syntax?
>>> Note that we could have for example Width(Ups->e+,ve,jet)~21 GeV, with Mass(Ups)=5000 GeV.
>>> Performing a quick check by computing separately (with CalcHEP) production cross section and BR it seems that their product is different from the cross section obtained with the syntax written above.
>>>
>>> Cheers,
>>> Matt.
>>>
>> --
>> If this answers your question, please go to the following page to let us
>> know that it is solved:
>> https://answers.launchpad.net/calchep/+question/661970/+confirm?answer_id=7
>>
>> If you still need help, you can reply to this email or go to the
>> following page to enter your feedback:
>> https://answers.launchpad.net/calchep/+question/661970
>>
>> You received this question notification because you asked the question.

Revision history for this message
Matt (elvin.j) said :
#11

Hi,

Thank you. I just want to add that in my case there are some 1->3 processes
that can also be realized via subdecays, for example:

 Ups -> u W^+ —> u e^+ \nu
Through gauge interactions, and

 Ups -> u e^+ \nu

Through just four-fermion contact interactions.

Best,
Matt

On 21 Jan 2018 8:37 p.m., "Alexander Pukhov" <
<email address hidden>> wrote:

Your question #661970 on CalcHEP changed:
https://answers.launchpad.net/calchep/+question/661970

    Status: Open => Answered

Alexander Pukhov proposed the following answer:
OK, Tomorrow I'll check a possibility to add 1->3 width to 1_2 one if
the user adds 1->3 events. I hope it will be easy to realize.

I'll write you tomorrow about success.

Possible problem from the user side. 1->3 should not be realized via
subdecays.

May be there are several 1->3 decay modes which we have to add.

I don't know how to add 1->3 and 1->4 automatically. Here there are a
lot of problems with double counting.

Sometimes, ( Hioggs -> W+,W-) 1->3 result is very far form correct
1->4.

Best

    Alexander Pukhov

On 01/21/2018 12:23 PM, Matt wrote:
> Question #661970 on CalcHEP changed:
> https://answers.launchpad.net/calchep/+question/661970
>
> Status: Answered => Open
>
> Matt is still having a problem:
> Hi,
>
> Ups has both 1->2 and 1->3 decays (and they have also comparable widths),
so this is exactly my problem!
> Is there a work around for this?
>
> Thanks a lot.
> Best,
>
> Matt
>
>> On 20 Jan 2018, at 14:43, Alexander Pukhov <question661970@answers.
launchpad.net> wrote:
>>
>> Your question #661970 on CalcHEP changed:
>> https://answers.launchpad.net/calchep/+question/661970
>>
>> Status: Open => Answered
>>
>> Alexander Pukhov proposed the following answer:
>> Does Ups have 1->2 decay mode?
>>
>> If Ups has 1->2 decay modes, then it will work as you expect but total
>> width of Ups will be calculated via 1->2 decays. So, if
>>
>> width Ups(1->2) >> width Ups(1-> e+,ve,jet) then result presented by
>> CalcHEP will be correct. Otherwise CalcHEP loses factor
>>
>> width(1->2)/(width(1->2) +width(1->3))
>>
>>
>> Let us know, Is it namely the problem that you meet?
>>
>> Best
>> Alexander Pukhov
>>
>>
>> On 12/19/2017 11:12 AM, Matt wrote:
>>> New question #661970 on CalcHEP:
>>> https://answers.launchpad.net/calchep/+question/661970
>>>
>>> Dear CalcHEP team,
>>>
>>> I am dealing with a model with heavy quarks interacting with both gauge
and contact interactions (implemented with an auxiliary vector boson) with
standard model particles. When I try to compute the contribution of one of
these quarks, let's say Ups, for the cross section of the process
p,p->e+,ve,jet,jet I usually use the following syntax:
>>> ...
>>> Process: p,p->Ups,jet
>>> Decay: Ups->e+,ve,jet
>>> ...
>>>
>>> So the question is: is CalcHEP computing the cross-section as
"production_cross_section*Branching_ratio" with this syntax?
>>> Note that we could have for example Width(Ups->e+,ve,jet)~21 GeV, with
Mass(Ups)=5000 GeV.
>>> Performing a quick check by computing separately (with CalcHEP)
production cross section and BR it seems that their product is different
from the cross section obtained with the syntax written above.
>>>
>>> Cheers,
>>> Matt.
>>>
>> --
>> If this answers your question, please go to the following page to let us
>> know that it is solved:
>> https://answers.launchpad.net/calchep/+question/661970/+
confirm?answer_id=7
>>
>> If you still need help, you can reply to this email or go to the
>> following page to enter your feedback:
>> https://answers.launchpad.net/calchep/+question/661970
>>
>> You received this question notification because you asked the question.

--
If this answers your question, please go to the following page to let us
know that it is solved:
https://answers.launchpad.net/calchep/+question/661970/+confirm?answer_id=9

If you still need help, you can reply to this email or go to the
following page to enter your feedback:
https://answers.launchpad.net/calchep/+question/661970

You received this question notification because you asked the question.

Revision history for this message
Launchpad Janitor (janitor) said :
#12

This question was expired because it remained in the 'Open' state without activity for the last 15 days.