MadGraph5_aMC@NLO

Events after cuts at parton level

Asked by SOUAD SEMLALI

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 cross-section 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 cross-section.

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 cross-section, before applying the standard cuts, and comparing the two cross-sections (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:
Expired
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#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
SOUAD SEMLALI (souad-sem) said : 		#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 cross-section
corresponding to each benchmark point is given below:

******************************************
BP1: Xs (MG without cuts, cut_decays = False) = 0.046 ± 0.0014pb,
          Xs(2hdmc+sushi) =0.00364
          Xs (MG with 10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False)
=0.005± 0.0001 pb
 An agreement between the cross-section 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(2hdmc+sushi) =0.0021 pb,
          Xs (10.0 = ptl1min, 8.0 = ptl2min, cut_decays = False) =0.0022 ±
 6.7e-05pb
 An agreement between the cross-section 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 cross-section 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://answers.launchpad.net/mg5amcnlo/+question/705859
>
> 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://answers.launchpad.net/mg5amcnlo/+question/705859/+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/mg5amcnlo/+question/705859
>
> You received this question notification because you asked the question.
>

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

Ah sorry,

Sorry, I miss read the two cross-section 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 cross-section 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
SOUAD SEMLALI (souad-sem) said : 		#4

Dear Olivier,

Thank you for your help.
I am using MG5-v2.9.5. I do get a warning about the tau width.

The higgs production cross section is given below:
========================================
 set wh1 2.003e-08, set wh2 4.697e-03

    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.924427e-08
# BR NDA ID1 ID2 ...
   8.842758e-01 2 -5 5 # 2.5860000249666e-08
   6.981539e-02 2 -4 4 # 2.0417001153153e-09
   4.530118e-02 2 -15 15 # 1.3247999392386e-09
   4.441896e-04 2 -3 3 # 1.2990000593592e-11
   1.620420e-04 2 -13 13 # 4.7387999993399995e-12
   1.106131e-06 2 -1 1 # 3.2347993619370004e-14
   2.831563e-07 2 -2 2 # 8.280699289401e-15
   3.790144e-09 2 -11 11 # 1.1083999447488e-16
#
# PDG Width
DECAY 35 8.399080e-03
# BR NDA ID1 ID2 ...
   6.437491e-01 2 -5 5 # 0.005406900190827999
   1.523262e-01 2 25 25 # 0.0012793999398959999

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.501e-02, B(h -> b b)= 8.212e-01, B(h -> ta ta)= 6.604e-02,
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://answers.launchpad.net/mg5amcnlo/+question/705859
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Ah sorry,
>
> Sorry, I miss read the two cross-section 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 cross-section 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://answers.launchpad.net/mg5amcnlo/+question/705859/+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/mg5amcnlo/+question/705859
>
> You received this question notification because you asked the question.
>

--
Souad SEMLALI

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#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 width-computation 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
SOUAD SEMLALI (souad-sem) said : 		#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_UFO__taudecay_UFO

I am using type1_hgg_UFO__taudecay_UFO to generate the events. The file
decays.py exists in THDM_tyep1_UFO model but not in the generated model
type1_hgg_UFO__taudecay_UFO, which is already forcing the auto
width-computation 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://answers.launchpad.net/mg5amcnlo/+question/705859
>
> 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 width-computation 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://answers.launchpad.net/mg5amcnlo/+question/705859/+confirm?answer_id=4
>
> 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/mg5amcnlo/+question/705859
>
> You received this question notification because you asked the question.
>

--
Souad SEMLALI

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said : 		#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_UFO__taudecay_UFO

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://answers.launchpad.net/mg5amcnlo/+question/705859
>
> 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_UFO__taudecay_UFO
>
> I am using type1_hgg_UFO__taudecay_UFO to generate the events. The file
> decays.py exists in THDM_tyep1_UFO model but not in the generated model
> type1_hgg_UFO__taudecay_UFO, which is already forcing the auto
> width-computation 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://answers.launchpad.net/mg5amcnlo/+question/705859
>>
>> 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 width-computation 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://answers.launchpad.net/mg5amcnlo/+question/705859/+confirm?answer_id=4
>>
>> 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/mg5amcnlo/+question/705859
>>
>> 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
SOUAD SEMLALI (souad-sem) said : 		#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://bugs.launchpad.net/mg5amcnlo/+bug/2012263
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://answers.launchpad.net/mg5amcnlo/+question/705859
>
> 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_UFO__taudecay_UFO
>
> 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://answers.launchpad.net/mg5amcnlo/+question/705859
> >
> > 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_UFO__taudecay_UFO
> >
> > I am using type1_hgg_UFO__taudecay_UFO to generate the events. The file
> > decays.py exists in THDM_tyep1_UFO model but not in the generated model
> > type1_hgg_UFO__taudecay_UFO, which is already forcing the auto
> > width-computation 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://answers.launchpad.net/mg5amcnlo/+question/705859
> >>
> >> 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 width-computation 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://answers.launchpad.net/mg5amcnlo/+question/705859/+confirm?answer_id=4
> >>
> >> 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/mg5amcnlo/+question/705859
> >>
> >> 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://answers.launchpad.net/mg5amcnlo/+question/705859/+confirm?answer_id=6
>
> 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/mg5amcnlo/+question/705859
>
> You received this question notification because you asked the question.
>

--
Souad SEMLALI

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

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