What information is used in reweighting?

Asked by Johann Brehmer

Dear Olivier et al,

I have yet one more question about the reweighting. I am trying to understand in detail which information is used to calculate the original and reweighted squared matrix elements (at LO). I am mostly able to follow the code in reweight_interface.py, up to line 1196 (in v2.6.6):

me_value = module.smatrixhel(pdg,p, event.aqcd, scale2, nhel)

Now SMATRIXHEL is in some dynamically generated library (allmatrix2py). I guess this somehow maps to the SMATRIX1 functions in the different matrix1.f in the SubProcesses folders?

In any case, are pdg and p just the final-state PDG IDs and four-momenta, or do they also include the initial states? In processes with decay chain syntax (p p > x, x > y y), is any information about the decaying intermediate particles included?

aqcd is alpha_s, right? I understand that scale2 does not matter for LO, is that correct? And with set helicity False, nhel is always -1, which then forces SMATRIXHEL to calculate the helicity sum?

In other words: does the matrix element calculated here depend on anything else exceot the final-state four-momenta, PDG ids, and helicities, as well as alpha_s?

Thanks a lot for all your help here!

Cheers,
Johann

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
Olivier Mattelaer (olivier-mattelaer) said :
#1

Hi,

> In any case, are pdg and p just the final-state PDG IDs and four-momenta, or do they also include the initial states?

This also includes initial state.

> In processes with decay chain syntax (p p > x, x > y y), is any information about the decaying intermediate particles included?

decay-chain are not fully support so far since no information about intermediate particles are used so far.
(in case of ambiguity, you need to have a strong ordering of your lhe file, and put an option in the re-weighting to use such strong ordering)

> aqcd is alpha_s, right? I understand that scale2 does not matter for LO, is that correct? And with set helicity False, nhel is always -1, which then forces SMATRIXHEL to calculate the helicity sum?

correct

> In other words: does the matrix element calculated here depend on anything else exceot the final-state four-momenta, PDG ids, and helicities, as well as alpha_s?

It obviously depend of the full matrix-element and they are also a special treatment of the mass if the reweight benchmarck is changing the mass of the final state.

Cheers,

Olivier

> On 11 Jul 2019, at 02:07, Johann Brehmer <email address hidden> wrote:
>
> New question #681910 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/681910
>
> Dear Olivier et al,
>
> I have yet one more question about the reweighting. I am trying to understand in detail which information is used to calculate the original and reweighted squared matrix elements (at LO). I am mostly able to follow the code in reweight_interface.py, up to line 1196 (in v2.6.6):
>
> me_value = module.smatrixhel(pdg,p, event.aqcd, scale2, nhel)
>
> Now SMATRIXHEL is in some dynamically generated library (allmatrix2py). I guess this somehow maps to the SMATRIX1 functions in the different matrix1.f in the SubProcesses folders?
>
> In any case, are pdg and p just the final-state PDG IDs and four-momenta, or do they also include the initial states? In processes with decay chain syntax (p p > x, x > y y), is any information about the decaying intermediate particles included?
>
> aqcd is alpha_s, right? I understand that scale2 does not matter for LO, is that correct? And with set helicity False, nhel is always -1, which then forces SMATRIXHEL to calculate the helicity sum?
>
> In other words: does the matrix element calculated here depend on anything else exceot the final-state four-momenta, PDG ids, and helicities, as well as alpha_s?
>
> Thanks a lot for all your help here!
>
> Cheers,
> Johann
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Johann Brehmer (johannbrehmer) said :
#2

Thanks, Olivier!

> decay-chain are not fully support so far since no information about intermediate particles are used so far.
> (in case of ambiguity, you need to have a strong ordering of your lhe file, and put an option in the re-weighting to use such strong ordering)

I'm not sure I understand this part. Does "ambiguity" refer to multiple decay topologies that are consistent with the final state and cannot be inferred from the final state? Will reweighting lead to wrong results in this case?

What is a "strong ordering" -- is this just about final state particles being in the same order, or also about intermediates?

What option do I have to use in the reweighting then? I couldn't find anything at https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/Reweight#Contentofthereweight_card ...

I'm asking all these questions because I am getting some weird results when reweighting
u u~ > t t~ h , h > a a , t > e+ ve b , t~ > mu- vm~ b~ .
I don't think there's any ambiguity in here. Is there anything I should look out for in this process?

Thanks a lot!
Johann

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

Hi,

I'm not sure I understand this part. Does "ambiguity" refer to multiple
decay topologies that are consistent with the final state and cannot be
inferred from the final state?

yes one example is
p p > w+ l+ l-, w+ > l+ vl
In that case an ambiguity is present when you have a l+ within your lhe file, to which "l+" you have to assign it to the matrix-element.

Will reweighting lead to wrong results in
this case?

It will crash and will give some instructions on how to use strong ordering in that case.

What option do I have to use in the reweighting then? I couldn't find
anything at
https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/Reweight#Contentofthereweight_card

At the moment, the only comment about this option is in the code (following that the code is the manual).
If/When you might need that option, it will be explained to you.

I'm asking all these questions because I am getting some weird results when reweighting
u u~ > t t~ h , h > a a , t > e+ ve b , t~ > mu- vm~ b~ .
I don't think there's any ambiguity in here. Is there anything I should look out for in this process?

No ambiguity here. For your issue, I do not know obviously.

Cheers,

Olivier

On 11 Jul 2019, at 14:52, Johann Brehmer <<email address hidden><mailto:<email address hidden>>> wrote:

Question #681910 on MadGraph5_aMC@NLO changed:
https://answers.launchpad.net/mg5amcnlo/+question/681910

   Status: Answered => Open

Johann Brehmer is still having a problem:
Thanks, Olivier!

decay-chain are not fully support so far since no information about intermediate particles are used so far.
(in case of ambiguity, you need to have a strong ordering of your lhe file, and put an option in the re-weighting to use such strong ordering)

I'm not sure I understand this part. Does "ambiguity" refer to multiple
decay topologies that are consistent with the final state and cannot be
inferred from the final state? Will reweighting lead to wrong results in
this case?

What is a "strong ordering" -- is this just about final state particles
being in the same order, or also about intermediates?

What option do I have to use in the reweighting then? I couldn't find
anything at
https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/Reweight#Contentofthereweight_card
...

I'm asking all these questions because I am getting some weird results when reweighting
u u~ > t t~ h , h > a a , t > e+ ve b , t~ > mu- vm~ b~ .
I don't think there's any ambiguity in here. Is there anything I should look out for in this process?

Thanks a lot!
Johann

--
You received this question notification because you are an answer
contact for MadGraph5_aMC@NLO.

Revision history for this message
Johann Brehmer (johannbrehmer) said :
#4

Thanks a lot!

Revision history for this message
Johann Brehmer (johannbrehmer) said :
#5

Thanks Olivier Mattelaer, that solved my question.