Follow-up question on HAHM_ggf_ZZd_4l generation for Z*

Asked by Jingjing Pan on 2020-09-21

Hi Olivier and Valentin,

We ran into this issue with running the HAHM_ggf_ZZd_4l model with MG5+Pythia8 last week, that we couldn't run the generation for off-shell Z bosons.

Olivier fixed the syntax in our job option file to syntactically allow off-shell Z bosons, i.e. "generate g g > h Z Zp > l+ l- l+ l-"

On the first trial there seemed to be an MG5-independent framework problem, which turned out to be occasional. We were later able to successfully complete the generation, while found that forcing m_Zd > 70 GeV put m_12 to zero.

Was wondering do you have any suggestions in that regard ? Any insights will be greatly appreciated!

Best,
Jing

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Jingjing Pan
Solved:
2020-09-25
Last query:
2020-09-25
Last reply:
2020-09-23

Hi,

Could you link the previous discussion?
Concerning your question here, I do not understand it at all and therefore can not comment on it. Can you reformulate it (and please remember that I do not know the model and what m_12 is )?

Cheers,

Olivier

Jingjing Pan (jp2555) said : #2

Hi Olivier,

Really sorry about not introducing the context.
We work on searching for Zd in the gg->H->Z(*)Zd->4l channel, and we'd like
to explore the case with mZd range 65~105 GeV.

We have modified the job option to as follows to allow Z to be off-shell.
The generation completed successfully while we found that the output mass
distribution for Z (which we refer to as "m12", the invariant mass of the
two leptonic decay products of Z, with m34 for Zd) became mostly zero when
setting mZd > 70GeV (at 5GeVsteps).

Please let me know if there is still anything unclear in this question!

Many thanks again,
Jing

-------------------------------------------------------------------------------------------------------
mzd = 75
evgenConfig.description="MadGraph Hidden Abelian Higgs Model (HAHM): gg ->
H -> ZZd -> 4l (l=e,mu) , with mZd=75GeV"
proc_card = """
import model HAHM_variableMW_v3_UFO
define l+ = e+ mu+
define l- = e- mu-
generate g g > h Z Zp > l+ l- l+ l-"""

proc_name = "HAHM_ggf_ZZd_4l_mZd75"

param_card_extras = { "HIDDEN": { 'epsilon': '1e-4', #kinetic mixing
parameter
                                 'kap': '1e-10', #higgs mixing parameter
                                 'mzdinput': mzd, #Zd mass
                                 'mhsinput':'200.0' }, #dark higgs mass
                     "HIGGS": { 'mhinput':'125.0'}, #higgs mass
                     "DECAY": { 'wzp':'Auto', 'wh':'Auto', 'wt':'Auto' }
#auto-calculate decay widths and BR of Zp, H, t
                  }

run_card_extras = { 'lhe_version':'2.0',
                   'cut_decays':'F',
                   'ptj':'0',
                   'ptb':'0',
                   'pta':'0',
                   'ptl':'0',
                   'etaj':'-1',
                   'etab':'-1',
                   'etaa':'-1',
                   'etal':'-1',
                   'drjj':'0',
                   'drbb':'0',
                   'drll':'0',
                   'draa':'0',
                   'drbj':'0',
                   'draj':'0',
                   'drjl':'0',
                   'drab':'0',
                   'drbl':'0',
                   'dral':'0' }

evgenConfig.keywords+=['exotic','BSMHiggs']
evgenConfig.contact = ['<email address hidden>']
evgenConfig.process = "HAHM_H_ZZd_4l"

include("MC15JobOptions/MadGraphControl_Pythia8_A14_NNPDF23LO_EvtGen_Common.py")

On Mon, Sep 21, 2020 at 10:15 AM Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #693026 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693026
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> Could you link the previous discussion?
> Concerning your question here, I do not understand it at all and therefore
> can not comment on it. Can you reformulate it (and please remember that I
> do not know the model and what m_12 is )?
>
> 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/693026/+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/693026
>
> You received this question notification because you asked the question.
>

With you syntax I would expect m_12 to be equal to m_34.
(if you use 12 as the first two lepton in the MG5aMC file)
Could you clarify the exact definition of m_12?

So I would expect to see at least two peaks on m_12, one at the Z mass, one at the Zp mass and likely one at zero.
Now what is the value of the width for the Z/Zp? I see that you use auto, but I would need the numerical value.

Cheers,

Olivier

Jingjing Pan (jp2555) said : #4

In terms of "m12", we obtained the plot by first identifying the two
leptons from Z and then computing "m12" as the di-lepton invariant mass.
Specifically, we used:

E = lep1.e() + lep2.e()

px = lep1.px() + lep2.px()

py = lep1.py() + lep2.py()

pz = lep1.pz() + lep2.pz()

invariantMassSq = (E**2 - px**2 - py**2 - pz**2)**0.5

I'm not quite sure if that corresponds to the "first two lepton in the
MG5aMC file". I also didn't find any output file of which the name
contained "MG5aMC" exactly. Could you please specify which file you are
referring to?

When setting mZd > 70GeV, there was only one peak centered at zero for m12.

Considering that the "on-shell' definition for Z is 91GeV+-15*Z width (or
54.5~127.5GeV), that output seemed to imply that the generation is not
working for off-shell Z, right?

Could you please guide me regarding which setting gives the numerical
values for Z/Zd decay widths, and which file contains that information?

Many thanks,

Jing

On Mon, Sep 21, 2020 at 11:25 AM Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #693026 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693026
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> With you syntax I would expect m_12 to be equal to m_34.
> (if you use 12 as the first two lepton in the MG5aMC file)
> Could you clarify the exact definition of m_12?
>
> So I would expect to see at least two peaks on m_12, one at the Z mass,
> one at the Zp mass and likely one at zero.
> Now what is the value of the width for the Z/Zp? I see that you use auto,
> but I would need the numerical value.
>
> 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/693026/+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/693026
>
> You received this question notification because you asked the question.
>

Hi,

The syntax
g g > h Z Zp > l+ l- l+ l-
does not ask that any particle are onshell.
You will therefore have multiple contribution
1) higgs onshell and Z onshell but Zp offshell
2) Higgs onshell and Zp onshell but Z offhell
3) Higgs offshell and Z onshell and Zp onshell
depending of your value of the width for Zp, other channel can be possible as well.

> In terms of "m12", we obtained the plot by first identifying the two
leptons from Z and then computing "m12" as the di-lepton invariant mass.
Specifically, we used:

The question is how do you do such identification?

> When setting mZd > 70GeV, there was only one peak centered at zero for m12.

Is mZd the pole mass here? or is it the invariant mass for m34 (whatever the definition of m34 is?

> I'm not quite sure if that corresponds to the "first two lepton in the
MG5aMC file". I also didn't find any output file of which the name
contained "MG5aMC" exactly. Could you please specify which file you are
referring to?

We have only one type of output file it is a file with extension .lhe (or .lhe.gz). At leading order it is typically
Events/run_01/unweighted_events.lhe.gz

> Could you please guide me regarding which setting gives the numerical
values for Z/Zd decay widths, and which file contains that information?

It should be written in the file above (in the banner, the line where you write "auto" has been replaced by the value.

Cheers,

Olivier

Jingjing Pan (jp2555) said : #6

Hi Olivier,

Thank you so much for your really detailed clarification.

>The question is how do you do such identification?

We do the naive ordered identification by

vectorBoson1 = higgsBoson.child(0)

vectorBoson2 = higgsBoson.child(1)

lepton1 = vectorBoson.child(0)

lepton2 = vectorBoson.child(1)

which seemed to work fine at least when the syntax put both Z and Zd to be
on-shell, but I'm not sure if there's further complication when not having
any of H, Z, Zd on-shell...

>Is mZd the pole mass here? or is it the invariant mass for m34 (whatever
the definition of m34 is?

By "mZd" we refer to 'mzdinput' in the param_card; not sure if that
corresponds to the "pole mass".

>It should be written in the file above (in the banner, the line where
you write "auto" has been replaced by the value.

When 'mzdinput' is 55 GeV, the decay width of Z is 2.4414, and the width of
Zd is 1.30975e-8.

PS: There was additional information for Zd decay that I'm not fully
understanding; included below in case it may be needed:

# PDG Width

DECAY 32 1.309751e-08

# BR NDA ID1 ID2 ...

   1.911790e-01 2 2 -2 # 2.50396911339e-09

   1.911339e-01 2 4 -4 # 2.50337805952e-09

   1.172397e-01 2 13 -13 # 1.53554803798e-09

   1.172397e-01 2 11 -11 # 1.53554803798e-09

   1.172157e-01 2 15 -15 # 1.53523316841e-09

   8.138643e-02 2 3 -3 # 1.06595948391e-09

   8.138643e-02 2 1 -1 # 1.06595948391e-09

   8.087789e-02 2 5 -5 # 1.05929891434e-09

   7.447096e-03 2 16 -16 # 9.75384084969e-11

   7.447096e-03 2 14 -14 # 9.75384084969e-11

   7.447096e-03 2 12 -12 # 9.75384084969e-11

Many thanks again!

Jing

On Mon, Sep 21, 2020 at 2:20 PM Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #693026 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693026
>
> Status: Open => Answered
>
> Olivier Mattelaer proposed the following answer:
> Hi,
>
> The syntax
> g g > h Z Zp > l+ l- l+ l-
> does not ask that any particle are onshell.
> You will therefore have multiple contribution
> 1) higgs onshell and Z onshell but Zp offshell
> 2) Higgs onshell and Zp onshell but Z offhell
> 3) Higgs offshell and Z onshell and Zp onshell
> depending of your value of the width for Zp, other channel can be possible
> as well.
>
> > In terms of "m12", we obtained the plot by first identifying the two
> leptons from Z and then computing "m12" as the di-lepton invariant mass.
> Specifically, we used:
>
> The question is how do you do such identification?
>
> > When setting mZd > 70GeV, there was only one peak centered at zero for
> m12.
>
> Is mZd the pole mass here? or is it the invariant mass for m34 (whatever
> the definition of m34 is?
>
>
> > I'm not quite sure if that corresponds to the "first two lepton in the
> MG5aMC file". I also didn't find any output file of which the name
> contained "MG5aMC" exactly. Could you please specify which file you are
> referring to?
>
> We have only one type of output file it is a file with extension .lhe (or
> .lhe.gz). At leading order it is typically
> Events/run_01/unweighted_events.lhe.gz
>
> > Could you please guide me regarding which setting gives the numerical
> values for Z/Zd decay widths, and which file contains that information?
>
> It should be written in the file above (in the banner, the line where
> you write "auto" has been replaced by the value.
>
> 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/693026/+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/693026
>
> You received this question notification because you asked the question.
>

Hi,

> which seemed to work fine at least when the syntax put both Z and Zd to be
> on-shell, but I'm not sure if there's further complication when not having
> any of H, Z, Zd on-shell...

Yes that's likely the issue: m_12 is not what you think it is.
Off-shell particles are not include in the event record due to the presence of other feynman diagram that can strongly interfere. This allows the parton-shower more freedom on how to shower the event and lead to more accurate result.

Cheers,

Olivier

> On 21 Sep 2020, at 22:10, Jingjing Pan <email address hidden> wrote:
>
> Question #693026 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693026
>
> Status: Answered => Open
>
> Jingjing Pan is still having a problem:
> Hi Olivier,
>
> Thank you so much for your really detailed clarification.
>
>> The question is how do you do such identification?
>
> We do the naive ordered identification by
>
> vectorBoson1 = higgsBoson.child(0)
>
> vectorBoson2 = higgsBoson.child(1)
>
> lepton1 = vectorBoson.child(0)
>
> lepton2 = vectorBoson.child(1)
>
>
> which seemed to work fine at least when the syntax put both Z and Zd to be
> on-shell, but I'm not sure if there's further complication when not having
> any of H, Z, Zd on-shell...
>
>> Is mZd the pole mass here? or is it the invariant mass for m34 (whatever
> the definition of m34 is?
>
> By "mZd" we refer to 'mzdinput' in the param_card; not sure if that
> corresponds to the "pole mass".
>
>> It should be written in the file above (in the banner, the line where
> you write "auto" has been replaced by the value.
>
> When 'mzdinput' is 55 GeV, the decay width of Z is 2.4414, and the width of
> Zd is 1.30975e-8.
>
> PS: There was additional information for Zd decay that I'm not fully
> understanding; included below in case it may be needed:
>
> # PDG Width
>
> DECAY 32 1.309751e-08
>
> # BR NDA ID1 ID2 ...
>
> 1.911790e-01 2 2 -2 # 2.50396911339e-09
>
> 1.911339e-01 2 4 -4 # 2.50337805952e-09
>
> 1.172397e-01 2 13 -13 # 1.53554803798e-09
>
> 1.172397e-01 2 11 -11 # 1.53554803798e-09
>
> 1.172157e-01 2 15 -15 # 1.53523316841e-09
>
> 8.138643e-02 2 3 -3 # 1.06595948391e-09
>
> 8.138643e-02 2 1 -1 # 1.06595948391e-09
>
> 8.087789e-02 2 5 -5 # 1.05929891434e-09
>
> 7.447096e-03 2 16 -16 # 9.75384084969e-11
>
> 7.447096e-03 2 14 -14 # 9.75384084969e-11
>
> 7.447096e-03 2 12 -12 # 9.75384084969e-11
>
>
> Many thanks again!
>
> Jing
>
> On Mon, Sep 21, 2020 at 2:20 PM Olivier Mattelaer <
> <email address hidden>> wrote:
>
>> Your question #693026 on MadGraph5_aMC@NLO changed:
>> https://answers.launchpad.net/mg5amcnlo/+question/693026
>>
>> Status: Open => Answered
>>
>> Olivier Mattelaer proposed the following answer:
>> Hi,
>>
>> The syntax
>> g g > h Z Zp > l+ l- l+ l-
>> does not ask that any particle are onshell.
>> You will therefore have multiple contribution
>> 1) higgs onshell and Z onshell but Zp offshell
>> 2) Higgs onshell and Zp onshell but Z offhell
>> 3) Higgs offshell and Z onshell and Zp onshell
>> depending of your value of the width for Zp, other channel can be possible
>> as well.
>>
>>> In terms of "m12", we obtained the plot by first identifying the two
>> leptons from Z and then computing "m12" as the di-lepton invariant mass.
>> Specifically, we used:
>>
>> The question is how do you do such identification?
>>
>>> When setting mZd > 70GeV, there was only one peak centered at zero for
>> m12.
>>
>> Is mZd the pole mass here? or is it the invariant mass for m34 (whatever
>> the definition of m34 is?
>>
>>
>>> I'm not quite sure if that corresponds to the "first two lepton in the
>> MG5aMC file". I also didn't find any output file of which the name
>> contained "MG5aMC" exactly. Could you please specify which file you are
>> referring to?
>>
>> We have only one type of output file it is a file with extension .lhe (or
>> .lhe.gz). At leading order it is typically
>> Events/run_01/unweighted_events.lhe.gz
>>
>>> Could you please guide me regarding which setting gives the numerical
>> values for Z/Zd decay widths, and which file contains that information?
>>
>> It should be written in the file above (in the banner, the line where
>> you write "auto" has been replaced by the value.
>>
>> 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/693026/+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/693026
>>
>> You received this question notification because you asked the question.
>>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Jingjing Pan (jp2555) said : #8

Hi Olivier,

>Off-shell particles are not include in the event record due to the presence of other feynman diagram that can strongly interfere. This allows the parton-shower more freedom on how to shower the event and lead to more accurate result.

Do you mean not included in the "event.lhe" file? Is there still any ways to access the off-shell particles' results?
Could you please provide us with some guide in that regard?

Much appreciated again,

Jing

> Do you mean not included in the "event.lhe" file?

Yes that information is not included (and should not be).

> Is there still any ways to access the off-shell particles' results?

They are so many situation that no this is not possible in general.
Now if you read your lhe file, you might find a way that works most of the times (but likely not all the time)

Cheers,

Olivier

> On 21 Sep 2020, at 23:01, Jingjing Pan <email address hidden> wrote:
>
> Question #693026 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693026
>
> Jingjing Pan posted a new comment:
> Hi Olivier,
>
>> Off-shell particles are not include in the event record due to the
> presence of other feynman diagram that can strongly interfere. This
> allows the parton-shower more freedom on how to shower the event and
> lead to more accurate result.
>
> Do you mean not included in the "event.lhe" file? Is there still any ways to access the off-shell particles' results?
> Could you please provide us with some guide in that regard?
>
> Much appreciated again,
>
> Jing
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Jingjing Pan (jp2555) said : #10

Hi Olivier,

>Now if you read your lhe file, you might find a way that works most of the
times (but likely not all the time)

Sorry, just to lastly make sure, you meant that the events.lhe file does
not (and should not) directly include any results for off-shell particles,
but one may be able to deduce some results for the off-shells from the lhe
file?

Much appreciated,
Jing

On Mon, Sep 21, 2020 at 5:15 PM Olivier Mattelaer <
<email address hidden>> wrote:

> Your question #693026 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693026
>
> Olivier Mattelaer proposed the following answer:
> > Do you mean not included in the "event.lhe" file?
>
> Yes that information is not included (and should not be).
>
> > Is there still any ways to access the off-shell particles' results?
>
>
> They are so many situation that no this is not possible in general.
> Now if you read your lhe file, you might find a way that works most of the
> times (but likely not all the time)
>
> Cheers,
>
> Olivier
>
> > On 21 Sep 2020, at 23:01, Jingjing Pan <
> <email address hidden>> wrote:
> >
> > Question #693026 on MadGraph5_aMC@NLO changed:
> > https://answers.launchpad.net/mg5amcnlo/+question/693026
> >
> > Jingjing Pan posted a new comment:
> > Hi Olivier,
> >
> >> Off-shell particles are not include in the event record due to the
> > presence of other feynman diagram that can strongly interfere. This
> > allows the parton-shower more freedom on how to shower the event and
> > lead to more accurate result.
> >
> > Do you mean not included in the "event.lhe" file? Is there still any
> ways to access the off-shell particles' results?
> > Could you please provide us with some guide in that regard?
> >
> > Much appreciated again,
> >
> > Jing
> >
> > --
> > 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/693026/+confirm?answer_id=8
>
> 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/693026
>
> You received this question notification because you asked the question.
>

Jingjing Pan (jp2555) said : #11

Hi Olivier,

Thanks for letting us know that off-shell Z bosons are not included in the event record. Our group had some discussion and was wondering could you please let us know which of the below is exactly the case:

when calculating the amplitude, the Feynman diagrams that involve off-shell particles are not taken into account;

or, the amplitude still counts the Feynman diagrams involving off-shell particles, and for the channel H > Z*Zp > 4l
so that we still have access to all of the four leptons, even though Z* is not accessible?

Much appreciated,
Jing

HI,

> when calculating the amplitude, the Feynman diagrams that involve off-shell particles are not taken into account;

This technically depend of your syntax. For this syntax: g g > h Z Zp > l+ l- l+ l-
the feynman diagram include the offshell contribution

> or, the amplitude still counts the Feynman diagrams involving off-shell particles, and for the channel H > Z*Zp > 4l
so that we still have access to all of the four leptons, even though Z* is not accessible?

Yes this is the case.

Olivierr

Jingjing Pan (jp2555) said : #13

Dear Olivier, thank you so much for all of you help. We are now able to reconstruct mZ* now.
Best,
Jing