Events after cuts at parton level
Dear MG team.
I am trying to generate events for the process (H > hh > 2b 2\tau), using the Library introduced in 1212.6247 to compute the tau decay.
generate g g > h2 > h1 h1, (h1 > b b~ YB<=1), (h1 > ta+ ta,ta+ > vt~ \mu+ vm, ta > vt e ve~ /w+ w h)
add process g g > h2 > h1 h1, (h1 > b b~ YB<=1), (h1 > ta+ ta,ta+ > v\t~ e+ ve, ta > vt mu vm~ /w+ w h)
The crosssection without cuts is larger than the predicted one by the model.
Xs (MG without cuts, cut_decays = False) = 0.022 pb, Xs(model) =0.0021 pb,
However, if I keep cut_decays = False to not enforce the standard cuts and I apply the following inclusive cuts on pt of the leading and subleading leptons
10.0 = ptl1min ! minimum pt for the leading lepton in pt
8.0 = ptl2min ! minimum pt for the second lepton in pt
I am getting a reasonable crosssection.
BP1: Xs (MG without cuts, cut_decays = False) = 0.046 pb,
Xs(model) =0.0021 pb,
Xs (10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False) =0.0022 pb
BP2: Xs (MG without cuts, cut_decays = False) = 0.022 pb,
Xs(model) =0.0021 pb,
Xs (10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False) =0.0022 pb
Do you think it's safe to apply the inclusive cuts to get a reasonable crosssection, before applying the standard cuts, and comparing the two crosssections (without cuts + inclusive cuts on ptlmin / with cuts + inclusive cuts on ptlmin) to check the number of events left after applying cuts at Parton level?
Many thanks for your help
Best
Question information
 Language:
 English Edit question
 Status:
 Open
 Assignee:
 No assignee Edit question
 Last query:
 Last reply:
Revision history for this message

#1 
Hi,
> Xs (MG without cuts, cut_decays = False) = 0.022 pb, Xs(model) =0.0021 pb
What is the statistical error on each number? Quoted like that, they are identical (up to the rounding error).
After that, I'm not really able to comment, since I'm afraid that I do not understand what you mean by
1) "model" (do you mean the number coming from a paper?)
2) BP1
3) BP2
Cheers,
Olivier
Revision history for this message

#2 
Dear Olivier,
Many thanks for your reply, and sorry for not explaining my problem well.
The model refers to the theoretical framework of our study, which is 2HDM.
I have selected 2 benchmark points, BP1 and BP2. The crosssection
corresponding to each benchmark point is given below:
*******
BP1: Xs (MG without cuts, cut_decays = False) = 0.046 ± 0.0014pb,
Xs (MG with 10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False)
=0.005± 0.0001 pb
An agreement between the crosssection computed while forcing inclusive
cuts on pTl and the one predicted by the model (0.0036~0.005 (pb))
*******
BP2: Xs (MG without cuts, cut_decays = False) = 0.022 ± 0.00061 pb,
Xs (10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False) =0.0022 ±
6.7e05pb
An agreement between the crosssection computed while forcing inclusive
cuts on pTl and the one predicted by the model (0.022~0.0021 (pb))
*******
"Xs (MG without cuts, cut_decays = False) = 0.022 pb, Xs(model) =0.0021
What is the statistical error on each number? Quoted like that, they are
identical (up to the rounding error)."
The difference between the crosssection without cuts and the theoretical
one is a factor of 10. However after applying the inclusive cuts, one can
get an agreement, but I am not sure if it is safe to consider these two (
Xs (MG with 10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False) vs.
Xs(2hdmc+sushi) ) comparable.
Best,
Souad
.
Le jeu. 16 mars 2023 à 16:11, Olivier Mattelaer <
<email address hidden>> a écrit :
> Your question #705859 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> > Xs (MG without cuts, cut_decays = False) = 0.022 pb, Xs(model) =0.0021
> pb
>
> What is the statistical error on each number? Quoted like that, they are
> identical (up to the rounding error).
>
>
> After that, I'm not really able to comment, since I'm afraid that I do not
> understand what you mean by
> 1) "model" (do you mean the number coming from a paper?)
> 2) BP1
> 3) BP2
>
> Cheers,
>
> Olivier
>
> 
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>
Revision history for this message

#3 
Ah sorry,
Sorry, I miss read the two crosssection and did not spot the factor 10. So yes this is clearly problematic and I would say that you need to understand the source of the difference before going forward.
Are you sure that all width are set correctly?
Did you compare the crosssection without the tau decay and without the Higgs decay?
Also which version of MG5aMC are you using?
In this computation the tau width is problematic in itself and if you use the real tau width within the computation you get issue due to numerical stability. If you use recent version of MG5aMC, you should see a warning for the tau width and a message indicating that MG5aMC is using a trick to avoid that issue. If you do not see such warning, then you likely use a too old version of the code.
Cheers,
Olivier
Revision history for this message

#4 
Dear Olivier,
Thank you for your help.
I am using MG5v2.9.5. I do get a warning about the tau width.
The higgs production cross section is given below:
=======
set wh1 2.003e08, set wh2 4.697e03
Xs(gg > h2) = 17.57 + 0.07016 pb, generate g g > h2 at LO
Xs(gg > h2 > h1 h1 ) = 4.767 + 0.01971 pb , generate g g > h2 >
h1 h1
Xs(gg > h2 > h1 h1 > bb tau tau ) = 0.7847 ± 0.0048, generate g g
> h2 > h1 h1, (h1 > b b~ YB<=1), (h1 > ta+ ta)
=======
Setting wh1 = auto, wh2 = auto
Xs(gg > h2 ) = 17.57 + 0.07016 pb, generate g g > h2
Xs(gg > h2 > h1 h1 ) = 2.666 ± 0.011 pb, generate g g > h2 > h1
h1
Xs(gg > h2 > h1 h1 > bb tau tau ) = 0.2059 ± 0.0013, generate g g
> h2 > h1 h1, (h1 > b b~ YB<=1), (h1 > ta+ ta)
# PDG Width
DECAY 25 2.924427e08
# BR NDA ID1 ID2 ...
8.842758e01 2 5 5 # 2.5860000249666e08
6.981539e02 2 4 4 # 2.0417001153153e09
4.530118e02 2 15 15 # 1.3247999392386e09
4.441896e04 2 3 3 # 1.2990000593592e11
1.620420e04 2 13 13 # 4.7387999993399
1.106131e06 2 1 1 # 3.2347993619370
2.831563e07 2 2 2 # 8.280699289401e15
3.790144e09 2 11 11 # 1.1083999447488e16
#
# PDG Width
DECAY 35 8.399080e03
# BR NDA ID1 ID2 ...
6.437491e01 2 5 5 # 0.0054069001908
1.523262e01 2 25 25 # 0.0012793999398
B(h2>h1h1) should be around 0.07!
=======
These are the input parameters:
set TB 18.26304
set sinbma 0.05867
set l2 0.25842e+00
set l3 0.45959e+00
set lr7 0.000000e+00
set mh1 40.24293e+00 # mh1
set mh2 1.250000e+02 # mh2
set mh3 92.81413e+00 # mh3
set mhc 123.50759e+00 # mhc
For such parameters the computed branching ratios by 2hdmc are: B(H > h
h) = 7.501e02, B(h > b b)= 8.212e01, B(h > ta ta)= 6.604e02,
leading to Xs(gg>h2>h1h1> 2b2tau)=0.0595 pb.
Many thanks for any suggestions or help to solve this problem.
Best
Souad
Le jeu. 16 mars 2023 à 21:30, Olivier Mattelaer <
<email address hidden>> a écrit :
> Your question #705859 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Ah sorry,
>
> Sorry, I miss read the two crosssection and did not spot the factor 10.
> So yes this is clearly problematic and I would say that you need to
> understand the source of the difference before going forward.
> Are you sure that all width are set correctly?
> Did you compare the crosssection without the tau decay and without the
> Higgs decay?
>
> Also which version of MG5aMC are you using?
> In this computation the tau width is problematic in itself and if you use
> the real tau width within the computation you get issue due to numerical
> stability. If you use recent version of MG5aMC, you should see a warning
> for the tau width and a message indicating that MG5aMC is using a trick to
> avoid that issue. If you do not see such warning, then you likely use a too
> old version of the code.
>
>
> Cheers,
>
> Olivier
>
> 
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>

Souad SEMLALI
Revision history for this message

#5 
So the issue is a difference in the computation of the Branching Ratio for h2 > h1 h1
This should be easy to settle since that computation is quite simple.
In your UFO model, do you have a file decays.py?
If yes it means that the partial width is computed analytically by FeynRules.
You can then remove that file completely and that would force that the auto widthcomputation to be done by madevent.
After that you can check if the computation of the width between FeynRules and MadEvent agrees or not.
Those two will likey agrees perfectly.
Then you should compare that result with the one of 2HDMC and compare the partial width for each decay mode and check what the difference between the two computation (does one computation have additional decay channel? does one decay channel does not agree/...) Then this will likely point to a difference in one parameter of the Lagrangian that explains this difference.
Cheers,
Olivier
Revision history for this message

#6 
Dear Olivier,
Many thanks for your reply. The UFO file I am using right now is created
from two add model in a row:
import model THDM_type1_UFO
add hgg_plugin
add model taudecay_UFO
=> model type1_hgg_
I am using type1_hgg_
decays.py exists in THDM_tyep1_UFO model but not in the generated model
type1_hgg_
widthcomputation to be done by madevent. Am I right?
Many thanks,
Best
Souad
Le ven. 17 mars 2023 à 14:55, Olivier Mattelaer <
<email address hidden>> a écrit :
> Your question #705859 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> So the issue is a difference in the computation of the Branching Ratio for
> h2 > h1 h1
> This should be easy to settle since that computation is quite simple.
>
> In your UFO model, do you have a file decays.py?
> If yes it means that the partial width is computed analytically by
> FeynRules.
> You can then remove that file completely and that would force that the
> auto widthcomputation to be done by madevent.
> After that you can check if the computation of the width between FeynRules
> and MadEvent agrees or not.
>
> Those two will likey agrees perfectly.
> Then you should compare that result with the one of 2HDMC and compare the
> partial width for each decay mode and check what the difference between the
> two computation (does one computation have additional decay channel? does
> one decay channel does not agree/...) Then this will likely point to a
> difference in one parameter of the Lagrangian that explains this difference.
>
> Cheers,
>
> Olivier
>
> 
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>

Souad SEMLALI
Revision history for this message

#7 
Correct,
But you can do the computation of the width (with both madevent and FeynRules) in the THDM_type1_UFO
and then check if the width of that model does match the width that you got from:
type1_hgg_
If the width differ between those two models, then this is also interesting since it means that it can be sensitive to the mass of light particle (that should be changed by the taudecay_UFO) or to the presence of the effective operator (imported by hgg_plugin)
Cheers,
Olivier
> On 17 Mar 2023, at 16:45, SOUAD SEMLALI <email address hidden> wrote:
>
> Question #705859 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Answered => Open
>
> SOUAD SEMLALI is still having a problem:
> Dear Olivier,
>
> Many thanks for your reply. The UFO file I am using right now is created
> from two add model in a row:
> import model THDM_type1_UFO
> add hgg_plugin
> add model taudecay_UFO
> => model type1_hgg_
>
> I am using type1_hgg_
> decays.py exists in THDM_tyep1_UFO model but not in the generated model
> type1_hgg_
> widthcomputation to be done by madevent. Am I right?
>
> Many thanks,
>
> Best
> Souad
>
> Le ven. 17 mars 2023 à 14:55, Olivier Mattelaer <
> <email address hidden>> a écrit :
>
>> Your question #705859 on MadGraph5_aMC@NLO changed:
>> https:/
>>
>> Status: Open => Answered
>>
>> Olivier Mattelaer proposed the following answer:
>> So the issue is a difference in the computation of the Branching Ratio for
>> h2 > h1 h1
>> This should be easy to settle since that computation is quite simple.
>>
>> In your UFO model, do you have a file decays.py?
>> If yes it means that the partial width is computed analytically by
>> FeynRules.
>> You can then remove that file completely and that would force that the
>> auto widthcomputation to be done by madevent.
>> After that you can check if the computation of the width between FeynRules
>> and MadEvent agrees or not.
>>
>> Those two will likey agrees perfectly.
>> Then you should compare that result with the one of 2HDMC and compare the
>> partial width for each decay mode and check what the difference between the
>> two computation (does one computation have additional decay channel? does
>> one decay channel does not agree/...) Then this will likely point to a
>> difference in one parameter of the Lagrangian that explains this difference.
>>
>> Cheers,
>>
>> Olivier
>>
>> 
>> If this answers your question, please go to the following page to let us
>> know that it is solved:
>>
>> https:/
>>
>> If you still need help, you can reply to this email or go to the
>> following page to enter your feedback:
>> https:/
>>
>> You received this question notification because you asked the question.
>>
>
>
> 
> Souad SEMLALI
>
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.
Revision history for this message

#8 
Dear Olivier,
Thank you for your help.
I am still having a problem, and I have reported the update of the issue
in: https:/
I would be grateful for any help or suggestion from your side to fix this
issue.
Many thanks
Best
Souad
Le ven. 17 mars 2023 à 16:00, Olivier Mattelaer <
<email address hidden>> a écrit :
> Your question #705859 on MadGraph5_aMC@NLO changed:
> https:/
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Correct,
>
> But you can do the computation of the width (with both madevent and
> FeynRules) in the THDM_type1_UFO
> and then check if the width of that model does match the width that you
> got from:
> type1_hgg_
>
> If the width differ between those two models, then this is also
> interesting since it means that it can be sensitive to the mass of light
> particle (that should be changed by the taudecay_UFO) or to the presence
> of the effective operator (imported by hgg_plugin)
>
> Cheers,
>
> Olivier
>
>
>
> > On 17 Mar 2023, at 16:45, SOUAD SEMLALI <
> <email address hidden>> wrote:
> >
> > Question #705859 on MadGraph5_aMC@NLO changed:
> > https:/
> >
> > Status: Answered => Open
> >
> > SOUAD SEMLALI is still having a problem:
> > Dear Olivier,
> >
> > Many thanks for your reply. The UFO file I am using right now is
> created
> > from two add model in a row:
> > import model THDM_type1_UFO
> > add hgg_plugin
> > add model taudecay_UFO
> > => model type1_hgg_
> >
> > I am using type1_hgg_
> > decays.py exists in THDM_tyep1_UFO model but not in the generated model
> > type1_hgg_
> > widthcomputation to be done by madevent. Am I right?
> >
> > Many thanks,
> >
> > Best
> > Souad
> >
> > Le ven. 17 mars 2023 à 14:55, Olivier Mattelaer <
> > <email address hidden>> a écrit :
> >
> >> Your question #705859 on MadGraph5_aMC@NLO changed:
> >> https:/
> >>
> >> Status: Open => Answered
> >>
> >> Olivier Mattelaer proposed the following answer:
> >> So the issue is a difference in the computation of the Branching Ratio
> for
> >> h2 > h1 h1
> >> This should be easy to settle since that computation is quite simple.
> >>
> >> In your UFO model, do you have a file decays.py?
> >> If yes it means that the partial width is computed analytically by
> >> FeynRules.
> >> You can then remove that file completely and that would force that the
> >> auto widthcomputation to be done by madevent.
> >> After that you can check if the computation of the width between
> FeynRules
> >> and MadEvent agrees or not.
> >>
> >> Those two will likey agrees perfectly.
> >> Then you should compare that result with the one of 2HDMC and compare
> the
> >> partial width for each decay mode and check what the difference between
> the
> >> two computation (does one computation have additional decay channel?
> does
> >> one decay channel does not agree/...) Then this will likely point to a
> >> difference in one parameter of the Lagrangian that explains this
> difference.
> >>
> >> Cheers,
> >>
> >> Olivier
> >>
> >> 
> >> If this answers your question, please go to the following page to let us
> >> know that it is solved:
> >>
> >>
> https:/
> >>
> >> If you still need help, you can reply to this email or go to the
> >> following page to enter your feedback:
> >> https:/
> >>
> >> You received this question notification because you asked the question.
> >>
> >
> >
> > 
> > Souad SEMLALI
> >
> > You received this question notification because you are an answer
> > contact for MadGraph5_aMC@NLO.
>
> 
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https:/
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https:/
>
> You received this question notification because you asked the question.
>

Souad SEMLALI
Can you help with this problem?
Provide an answer of your own, or ask SOUAD SEMLALI for more information if necessary.