MadGraph5_aMC@NLO

tau pair production

Asked by A.Hayreter

Dear MG5 support members,

I have a rather simple question, I am working on MG5.v1.5.9. And here are the steps that I am going through;

Step 1:
p p > ta+ ta- / a

I produce tau pair in only Z exchange channel at 7TeV CM energy with default 10000 events and cteq6l1 pdf set.
MG5 calculates the cross-section as 378.9 pb. Then I wanted to proceed with full leptonic decays of taus in dimuon
channel, since pdg reports the br(ta- > mu- vm~ vt) = %17.41 I would expect to get 378.9*(0.1741)^2 = 11.48 pb.
so the next step is;

Step 2:
generate p p > ta+ ta- / a ,\
(ta+ > w+ vt~, w+ > mu+ vm) ,\
(ta- > w- vt, w- > mu- vm~)

Now the cross-section is 8.916E-09 pb. !!! Then I noticed that with this definition of the process W bosons are
produced on-shell, which in return would significantly reduce the cross-section. And the last step;

Step 3:
p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a

now W bosons are allowed to be off-shell, however, cross-section is 9.187E-09 pb. !!!!!!!!!! not even a tiny improvement.
By the way the following definition fails although it has the same structure with the above one;

generate p p > ta+ ta- / a ,\
(ta+ > vt~ mu+ vm) ,\
(ta- > vt mu- vm~)

and gives the following error message;

"(ta- > vt mu- vm~) @1" with error:
InvalidCmd : Missing ending parenthesis for decay process

am I missing anything? could you please confirm my results.

thanks in advance.

Alper.

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Best Olivier Mattelaer (olivier-mattelaer) said : 		#1

Hi Alper,

In fact the default sm model has the tau width set to zero. If you use that model then you will have not be able to decay the tau correctly.
The model that I use for having the result below is "sm-full" where you can check that the tau width is not forced to be zero.

A second point, is to be sure that your run_card has the parameter
cut_decays set on False, otherwise you will never have the correct BR with your method.

You need to be careful in this case since the with of the tau is extremely small (i.e. at the level of the computer precision).
A nice trick is to generate the sample with an artificially large width (such as 1e-5) and then rescale the total cross-section
by the appropriate factor (which is simply the ratio of the widths due to the narrow width approximation). This can improve the generation time by a huge factor. For having the exact same distributions at the end. I didn't use that trick below since the code seems stable and fast enough.

> Step 1:
> p p > ta+ ta- / a
>
> I produce tau pair in only Z exchange channel at 7TeV CM energy with default 10000 events and cteq6l1 pdf set.

I would advise to use instead the following syntax:
p p > z, z > ta+ ta-
which forces the z to be on-shell since otherwise you can't neglect the interference with the photon.
this gives 1622 +- 1.022 pb (@14TeV)
which is of course slightly lower tan
p p > ta+ ta- / a (1643) due to the invariant mass cut on the Z.
(all the other cuts need to be remove for that generation to have this number)
The difference between the two cross-section correspond to very off-shell Z, where selecting a single diagram is not physical.

> Step 2:
> generate p p > ta+ ta- / a ,\
> (ta+ > w+ vt~, w+ > mu+ vm) ,\
> (ta- > w- vt, w- > mu- vm~)

this is indeed not correct since the W cann't be onshell.

> Step 3:
> p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a

I would say that the correct syntax is
p p > z, ( z > ta- ta+, ta- > vt mu- vm~, ta+ > vt~ mu+ vm)
this gives: 42.68
I didn't check but
> p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a
 should give the same cross-section (up to BW_cut efficiency) if you remove all cuts in the run_card.
(I have check that both gives the same cross-section with the default cut)

So this gives a branching fraction of 0.1672303297700105
(if you take into accout a efficiency of 98% for the cut on the invariant mass for the )

Cheers,

Olivier

On Apr 27, 2013, at 5:41 AM, A.Hayreter <email address hidden> wrote:

> Question #227597 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/227597
>
> Description changed to:
> Dear MG5 support members,
>
> I have a rather simple question, I am working on MG5.v1.5.9. And here
> are the steps that I am going through;
>
> Step 1:
> p p > ta+ ta- / a
>
> I produce tau pair in only Z exchange channel at 7TeV CM energy with default 10000 events and cteq6l1 pdf set.
> MG5 calculates the cross-section as 378.9 pb. Then I wanted to proceed with full leptonic decays of taus in dimuon
> channel, since pdg reports the br(ta- > mu- vm~ vt) = %17.41 I would expect to get 378.9*(0.1741)^2 = 11.48 pb.
> so the next step is;
>
> Step 2:
> generate p p > ta+ ta- / a ,\
> (ta+ > w+ vt~, w+ > mu+ vm) ,\
> (ta- > w- vt, w- > mu- vm~)
>
> Now the cross-section is 8.916E-09 pb. !!! Then I noticed that with this definition of the process W bosons are
> produced on-shell, which in return would significantly reduce the cross-section. And the last step;
>
> Step 3:
> p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a
>
> now W bosons are allowed to be off-shell, however, cross-section is 9.187E-09 pb. !!!!!!!!!! not even a tiny improvement.
> By the way the following definition fails although it has the same structure with the above one;
>
> generate p p > ta+ ta- / a ,\
> (ta+ > vt~ mu+ vm) ,\
> (ta- > vt mu- vm~)
>
> and gives the following error message;
>
> "(ta- > vt mu- vm~) @1" with error:
> InvalidCmd : Missing ending parenthesis for decay process
>
> am I missing anything? could you please confirm my results.
>
> thanks in advance.
>
> Alper.
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Revision history for this message
A.Hayreter (alperhayreter) said : 		#2

Hi Olivier,

thank you very much, your answer is quite satisfactory and definitely
solves my problem.
I just have a small question, I think "sm-full" is an option in "sm" model
file. What if I need
to implement a new model that requires this "sm-full" features? How do I
include those
features? I couldn't find in FeynRules.

thanks a lot.

On Sun, Apr 28, 2013 at 8:31 AM, Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #227597 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/227597
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi Alper,
>
> In fact the default sm model has the tau width set to zero. If you use
> that model then you will have not be able to decay the tau correctly.
> The model that I use for having the result below is "sm-full" where you
> can check that the tau width is not forced to be zero.
>
> A second point, is to be sure that your run_card has the parameter
> cut_decays set on False, otherwise you will never have the correct BR with
> your method.
>
> You need to be careful in this case since the with of the tau is extremely
> small (i.e. at the level of the computer precision).
> A nice trick is to generate the sample with an artificially large width
> (such as 1e-5) and then rescale the total cross-section
> by the appropriate factor (which is simply the ratio of the widths due to
> the narrow width approximation). This can improve the generation time by a
> huge factor. For having the exact same distributions at the end. I didn't
> use that trick below since the code seems stable and fast enough.
>
> > Step 1:
> > p p > ta+ ta- / a
> >
> > I produce tau pair in only Z exchange channel at 7TeV CM energy with
> default 10000 events and cteq6l1 pdf set.
>
> I would advise to use instead the following syntax:
> p p > z, z > ta+ ta-
> which forces the z to be on-shell since otherwise you can't neglect the
> interference with the photon.
> this gives 1622 +- 1.022 pb (@14TeV)
> which is of course slightly lower tan
> p p > ta+ ta- / a (1643) due to the invariant mass cut on the Z.
> (all the other cuts need to be remove for that generation to have this
> number)
> The difference between the two cross-section correspond to very off-shell
> Z, where selecting a single diagram is not physical.
>
>
> > Step 2:
> > generate p p > ta+ ta- / a ,\
> > (ta+ > w+ vt~, w+ > mu+ vm) ,\
> > (ta- > w- vt, w- > mu- vm~)
>
> this is indeed not correct since the W cann't be onshell.
>
> > Step 3:
> > p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a
>
> I would say that the correct syntax is
> p p > z, ( z > ta- ta+, ta- > vt mu- vm~, ta+ > vt~ mu+ vm)
> this gives: 42.68
> I didn't check but
> > p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a
> should give the same cross-section (up to BW_cut efficiency) if you remove
> all cuts in the run_card.
> (I have check that both gives the same cross-section with the default cut)
>
> So this gives a branching fraction of 0.1672303297700105
> (if you take into accout a efficiency of 98% for the cut on the invariant
> mass for the )
>
> Cheers,
>
> Olivier
>
>
> On Apr 27, 2013, at 5:41 AM, A.Hayreter <
> <email address hidden>> wrote:
>
> > Question #227597 on MadGraph5 changed:
> > https://answers.launchpad.net/madgraph5/+question/227597
> >
> > Description changed to:
> > Dear MG5 support members,
> >
> > I have a rather simple question, I am working on MG5.v1.5.9. And here
> > are the steps that I am going through;
> >
> > Step 1:
> > p p > ta+ ta- / a
> >
> > I produce tau pair in only Z exchange channel at 7TeV CM energy with
> default 10000 events and cteq6l1 pdf set.
> > MG5 calculates the cross-section as 378.9 pb. Then I wanted to proceed
> with full leptonic decays of taus in dimuon
> > channel, since pdg reports the br(ta- > mu- vm~ vt) = %17.41 I would
> expect to get 378.9*(0.1741)^2 = 11.48 pb.
> > so the next step is;
> >
> > Step 2:
> > generate p p > ta+ ta- / a ,\
> > (ta+ > w+ vt~, w+ > mu+ vm) ,\
> > (ta- > w- vt, w- > mu- vm~)
> >
> > Now the cross-section is 8.916E-09 pb. !!! Then I noticed that with this
> definition of the process W bosons are
> > produced on-shell, which in return would significantly reduce the
> cross-section. And the last step;
> >
> > Step 3:
> > p p > ta+ ta- > vt~ mu+ vm vt mu- vm~ / a
> >
> > now W bosons are allowed to be off-shell, however, cross-section is
> 9.187E-09 pb. !!!!!!!!!! not even a tiny improvement.
> > By the way the following definition fails although it has the same
> structure with the above one;
> >
> > generate p p > ta+ ta- / a ,\
> > (ta+ > vt~ mu+ vm) ,\
> > (ta- > vt mu- vm~)
> >
> > and gives the following error message;
> >
> > "(ta- > vt mu- vm~) @1" with error:
> > InvalidCmd : Missing ending parenthesis for decay process
> >
> > am I missing anything? could you please confirm my results.
> >
> > thanks in advance.
> >
> > Alper.
> >
> > --
> > You received this question notification because you are a member of
> > MadTeam, which is an answer contact for MadGraph5.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https://answers.launchpad.net/madgraph5/+question/227597/+confirm?answer_id=0
>
> 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/madgraph5/+question/227597
>
> You received this question notification because you asked the question.
>

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#3

Hi Alper,

>I just have a small question, I think "sm-full" is an option in "sm" model file.

Yes and no.

First in order to use the sm-full model, you just have to do: import model sm-full.
This correspond in fact to the exact UFO model with no special restriction.

Let me explain.
In general, you can restrict your UFO model with a file restrict_XXXX.dat. This files is in fact a param_card, and MG5 removes
all the interactions which are zero with that param_card.dat (and removes the associated zero/one parameter)
(All details are explained in the MG5 paper). The important point is that in order to load that restriction inside MG5
you have to do:
import model MODELNAME-XXXX
where XXXX match the name of the restrict file.

However they are one exception:
if you have the file
restrict_default.dat
then the restriction is load automatically
(so import model sm, performs the restriction associated to the file restrict_default.dat)
In order to forbid the automatic restriction you can do
import model MODELNAME-full
which will NOT perform any restriction.
import model ssm-full correspond therefore to the original UFO model.

 >What if I need
>to implement a new model that requires this "sm-full" features? How do I
>include those
>features? I couldn't find in FeynRules.

Those restriction are purely linked to MadGraph and are not part of the UFO agreement and/or supported by FeynRules.

I hope that I have answer your question (not 100% sure). If not don't hesitate to tell me.

Cheers,

Olivier

Revision history for this message
A.Hayreter (alperhayreter) said : 		#4

yes, this is what I wanted to know, thanks again Olivier.

Cheers.

On Mon, Apr 29, 2013 at 2:21 PM, Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #227597 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/227597
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi Alper,
>
> >I just have a small question, I think "sm-full" is an option in "sm"
> model file.
>
> Yes and no.
>
> First in order to use the sm-full model, you just have to do: import model
> sm-full.
> This correspond in fact to the exact UFO model with no special restriction.
>
> Let me explain.
> In general, you can restrict your UFO model with a file restrict_XXXX.dat.
> This files is in fact a param_card, and MG5 removes
> all the interactions which are zero with that param_card.dat (and removes
> the associated zero/one parameter)
> (All details are explained in the MG5 paper). The important point is that
> in order to load that restriction inside MG5
> you have to do:
> import model MODELNAME-XXXX
> where XXXX match the name of the restrict file.
>
> However they are one exception:
> if you have the file
> restrict_default.dat
> then the restriction is load automatically
> (so import model sm, performs the restriction associated to the file
> restrict_default.dat)
> In order to forbid the automatic restriction you can do
> import model MODELNAME-full
> which will NOT perform any restriction.
> import model ssm-full correspond therefore to the original UFO model.
>
> >What if I need
> >to implement a new model that requires this "sm-full" features? How do I
> >include those
> >features? I couldn't find in FeynRules.
>
> Those restriction are purely linked to MadGraph and are not part of the
> UFO agreement and/or supported by FeynRules.
>
> I hope that I have answer your question (not 100% sure). If not don't
> hesitate to tell me.
>
> Cheers,
>
> Olivier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https://answers.launchpad.net/madgraph5/+question/227597/+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/madgraph5/+question/227597
>
> You received this question notification because you asked the question.
>

Revision history for this message
A.Hayreter (alperhayreter) said : 		#5

Hi Olivier,

I need to keep this question open for the moment
since I am having some troubles with a new model.
Ok, here it is;
Using FeynRules I generated a new UFO model file
which contains tau width (2.27*10^-12) as well. Then
I followed exactly the same pattern that you advised
above. Since I do not have any restriction files I first
imported my model as
import model_UFO
I get zero as a result, and MG5 complains about that
then I tried
import model_UFO-full
still getting zero with the same complaint.

Then I checked default sm model directory in MG5
and the one that I generated by FR. Besides restriction
files there are couple of extra files in default sm model
directory. Among those the most relevant is decays.py
file which contains partial widths of all decaying particles.
I do not have this file from FR. Is this simply problem of FR?
can I simply copy and paste decays.py file to my folder and
would it work properly?

thanks in advance Olivier.

Alper.

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#6

Hi Alper,

> I get zero as a result, and MG5 complains about that

Are you sure that all coupling are set correctly?
On that point, you can check that Matrix element is different of zero for a random phase-space point:
import model UFO
generate XXXXXX
output standalone
launch

Otherwise, cross-check the value of all width of the model.

> Then I checked default sm model directory in MG5
> and the one that I generated by FR. Besides restriction
> files there are couple of extra files in default sm model
> directory. Among those the most relevant is decays.py
> file which contains partial widths of all decaying particles.
> I do not have this file from FR. Is this simply problem of FR?
> can I simply copy and paste decays.py file to my folder and
> would it work properly?

In order to get this files from FR, you need to use the development version of FR.
But this will not help you in anyway for your problem, since you don't use this files.

If you think that the above problem might be due to a bug, then don't hesitate
to send me your model and precise instructions.

Cheers,

Olivier

On May 3, 2013, at 5:51 PM, A.Hayreter <email address hidden> wrote:

> Question #227597 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/227597
>
> A.Hayreter gave more information on the question:
> Hi Olivier,
>
> I need to keep this question open for the moment
> since I am having some troubles with a new model.
> Ok, here it is;
> Using FeynRules I generated a new UFO model file
> which contains tau width (2.27*10^-12) as well. Then
> I followed exactly the same pattern that you advised
> above. Since I do not have any restriction files I first
> imported my model as
> import model_UFO
> I get zero as a result, and MG5 complains about that
> then I tried
> import model_UFO-full
> still getting zero with the same complaint.
>
> Then I checked default sm model directory in MG5
> and the one that I generated by FR. Besides restriction
> files there are couple of extra files in default sm model
> directory. Among those the most relevant is decays.py
> file which contains partial widths of all decaying particles.
> I do not have this file from FR. Is this simply problem of FR?
> can I simply copy and paste decays.py file to my folder and
> would it work properly?
>
> thanks in advance Olivier.
>
> Alper.
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Revision history for this message
A.Hayreter (alperhayreter) said : 		#7

I found the problem, it was simply a syntax issue at the process generation level.
thanks a lot Olivier.

Revision history for this message
A.Hayreter (alperhayreter) said : 		#8

Thanks Olivier Mattelaer, that solved my question.

Revision history for this message
Jon Parry (jkparry1978) said : 		#9

Hi

I'm also having trouble with decaying tau's, so I tried to reproduce what was suggested in this thread but with no luck. Let me explain what I did. I used the following commands, for MG5_aMC v2.1.0

>import model sm-full
>generate p p > z , z> ta+ ta-

launching this I find 1622 pb at 14 TeV as stated above. Next I tried,

> generate p p > z , (z > ta+ ta-, ta+ > mu+ vm vt~, ta- > mu- vm~ vt)

launching this I made sure that the tau width was non-zero in param_card.dat (I also tried to increase it to 1e-5), turned off all cuts, set cut_decays =F in run_card.dat, but the resulting x-sec was very small like 1e-8. I also tried increasing bwcutoff from 15 to 50 in case it was something to do with the off-shell W in the tau decay, but the result was the same.

What have I missed?

Thanks

Jon

Revision history for this message
A.Hayreter (alperhayreter) said : 		#10

Hi Jon,

did you get your problem solved?

Revision history for this message
Jon Parry (jkparry1978) said : 		#11

Hi

I updated to the latest version of Madgraph5 and the it solved the problem.

Thanks