small width particle

Asked by Halley_X

Hi,

I generate a process with InertDoublet_UFO model, there are unstable particles in the process like A0 and Z, the decay width of A0 is small (3.6*10^-5), so I see a warning when running the code
WARNING: Particle 36 with small width detected (3.6e-05): See https://answers.launchpad.net/mg5amcnlo/+faq/3053 to learn the special handling of that case
If it mean that the mg5 handle the small width by using a default fake value and I don't need do anything about it?
Another question is that when I check the gauge invariance of this process, I get
Lorentz invariance results:
Process Min element Max element Relative diff. Result
e+ e- > e+ e- h2 1.9925531382e-23 1.9925531419e-23 1.8823662428e-09 Failed
   JAMP 0 1.5940425105e-22 1.5940425135e-22 1.8823658003e-09 Failed
Summary: 0/1 passed, 1/1 failed
I haven't exclude any diagrams so I'm confused about it.
I'll be really appreciate it if you could help me.

Best wishes,
Halley

Question information

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

Hi,

Concerning your first question,
Yes this is correct, MG5aMC use that trick to avoid numerical inacurracy fully automatically in that case.
This has obviously some (very very small) impact on the distribution (starting obviously by the one of the invariant mass of the A0 particle) and you should be aware of that.

Another question is that when I check the gauge invariance of this process, I get
Lorentz invariance results:
Process Min element Max element Relative diff. Result
e+ e- > e+ e- h2 1.9925531382e-23 1.9925531419e-23 1.8823662428e-09 Failed
  JAMP 0 1.5940425105e-22 1.5940425135e-22 1.8823658003e-09 Failed
Summary: 0/1 passed, 1/1 failed
I haven't exclude any diagrams so I'm confused about it.
I'll be really appreciate it if you could help me.

Personally, when I do run the following command:
import model InertDoublet_UFO #fresh from the database
generate e+ e- > e+ e- h2
I do get:
NoDiagramException : No amplitudes generated from process Process: e+ e- > e+ e- h2 WEIGHTED=3 @1. Please enter a valid process

So I guess that we do not use the same model (and/or process)
Now I do observe that
1) the min/max element are both very very small (for e+ e- > e+ e- Z those are at ~1e-7)
2) the relative difference is not super/super bad (1e-9)

So this is possible that the reason here is numerical precision since the amplitude itself is suppressed.
(Would you have large interference?)

Cheers,

Olivier

> On 30 Oct 2022, at 14:50, Halley_X <email address hidden> wrote:
>
> New question #703644 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/703644
>
> Hi,
>
> I generate a process with InertDoublet_UFO model, there are unstable particles in the process like A0 and Z, the decay width of A0 is small (3.6*10^-5), so I see a warning when running the code
> WARNING: Particle 36 with small width detected (3.6e-05): See https://answers.launchpad.net/mg5amcnlo/+faq/3053 to learn the special handling of that case
> If it mean that the mg5 handle the small width by using a default fake value and I don't need do anything about it?
> Another question is that when I check the gauge invariance of this process, I get
> Lorentz invariance results:
> Process Min element Max element Relative diff. Result
> e+ e- > e+ e- h2 1.9925531382e-23 1.9925531419e-23 1.8823662428e-09 Failed
> JAMP 0 1.5940425105e-22 1.5940425135e-22 1.8823658003e-09 Failed
> Summary: 0/1 passed, 1/1 failed
> I haven't exclude any diagrams so I'm confused about it.
> I'll be really appreciate it if you could help me.
>
> Best wishes,
> Halley
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Halley_X (neuromance) said :
#2

Thanks for your quick reply.
I'm sorry I put an incorrect process, my process is: e+ e- > e+ e- h0 h0
my benchmark points are
   10 -4.40700e-03 # lamL
   11 1.445000e+00 # lam2
   12 1.250000e+02 # mmh
   13 7.277000e+01 # mmH0
   14 1.078000e+02 # mmA0
   15 1.146000e+02 # mmHch
and the decay width
DECAY 6 2.000000e+00 # WT
DECAY 23 2.495200e+00 # WZ
DECAY 24 2.085000e+00 # WW
DECAY 25 0.000000e+00 # Wh
DECAY 35 0.000000e+00 # WH0
DECAY 36 3.600000e-05 # WA0
DECAY 37 0.000000e+00 # WHch

The cross section I get is about 0.16 fb at center-of-mass energy of 380gev, and is different with the result of a published paper(about 2~3 fb). So I wonder if the small width influences the result, and why gauge invariance is failed.

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

OK here I do have a process.
But the lorentz invariance is working fine here (tested for that benchmark and that energy):

MG5_aMC>check lorentz ./PROC_InertDoublet_UFO_0/Cards/param_card.dat e+ e- > e+ e- h h --energy=380
check: Samurai not available on your system; it will be skipped.
check: Ninja not available on your system; it will be skipped.
INFO: Set All width to zero for non complex mass scheme checks
INFO: Checking lorentz transformations for process e+ e- > e+ e- h h
check: 1 check performed in 0 second
INFO: Note That all width have been set to zero for those checks

Lorentz invariance results:
Process Min element Max element Relative diff. Result
e+ e- > e+ e- h h3.3579285671e-13 3.3579285671e-13 8.7204108773e-15 Passed
Summary: 1/1 passed, 0/1 failed

Now for the cross-section, which version of MG5aMC did you use and which PDF did you use? (if any)
I have tested isronly and not too surprising the effect is limited (and actually decrease the cross-section).
Now the cross-section that I get is this one:

Without PDF (and using the LTS) I do get the following result:
     Cross-section : 1.402e-06 +- 3.319e-09 pb
     Nb of events : 10000

With ISR radiation (and no cut using the nightly build (the model seems not supported for 3.4.1))
  === Results Summary for run: run_02 tag: tag_1 ===

     Cross-section : 1.092e-06 +- 2.686e-09 pb
     Nb of events : 10000

Cheers,

Olivier

> On 30 Oct 2022, at 19:20, Halley_X <email address hidden> wrote:
>
> Question #703644 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/703644
>
> Status: Answered => Open
>
> Halley_X is still having a problem:
> Thanks for your quick reply.
> I'm sorry I put an incorrect process, my process is: e+ e- > e+ e- h0 h0
> my benchmark points are
> 10 -4.40700e-03 # lamL
> 11 1.445000e+00 # lam2
> 12 1.250000e+02 # mmh
> 13 7.277000e+01 # mmH0
> 14 1.078000e+02 # mmA0
> 15 1.146000e+02 # mmHch
> and the decay width
> DECAY 6 2.000000e+00 # WT
> DECAY 23 2.495200e+00 # WZ
> DECAY 24 2.085000e+00 # WW
> DECAY 25 0.000000e+00 # Wh
> DECAY 35 0.000000e+00 # WH0
> DECAY 36 3.600000e-05 # WA0
> DECAY 37 0.000000e+00 # WHch
>
> The cross section I get is about 0.16 fb at center-of-mass energy of
> 380gev, and is different with the result of a published paper(about 2~3
> fb). So I wonder if the small width influences the result, and why gauge
> invariance is failed.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Halley_X (neuromance) said :
#4

Thanks Olivier.
I check my process again according to your command: check lorentz ./PROC_InertDoublet_UFO_0/Cards/param_card.dat e+ e- > e+ e- h2 h2 --energy=380. I notice that your final state particle is different with mine, my final state particle is h2 not h. And still lorentz invariance is failed for my process.
My mg5 version is 3.1.1, and pdf is 0 because the initial states are electrons.

Best wishes,
Halley

Revision history for this message
Halley_X (neuromance) said :
#5

Hi,

There are unstable particles in my process, could lorentz invariance be broken if the default scheme is fixed width or narrow width approximation ?

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

Hi,

> could lorentz invariance be
> broken if the default scheme is fixed width

No because the check of the lorentz invariance is done with all width set to zero
to remove the issue of the fixed width.
If the complex mass-scheme is on True, then the check is done with full width.

> or narrow width
> approximation ?

They are no narrow width approximation here even the phase-space point used is likely fully offshell since it is using RAMBO to generate the point that is used for the check.

Cheers,

Olivier

> On 31 Oct 2022, at 08:00, Halley_X <email address hidden> wrote:
>
> Question #703644 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/703644
>
> Halley_X gave more information on the question:
> Hi,
>
> There are unstable particles in my process, could lorentz invariance be
> broken if the default scheme is fixed width or narrow width
> approximation ?
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

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

Hi,
Your issue seems to be related to the electron mass.
If I restrict your model to remove the electron mass (and therefore the h e+ e- interactions) then I do have lorentz invariance restored. (see the FAQ to know how to do that)

Cheers,

Olivier

PS: It also reduces the computation from 40 diagram to 8, meaning the computation will be faster.
PPS: this seems to change the cross-section by a factor of two if you use or not such restriction which seems to indicates that you are sensitive to numerical effect without the restriction

FAQ #2312: “FR Model much slower than build-in MG model. Why and how to fix?”.

Revision history for this message
Halley_X (neuromance) said :
#8

Many thanks, Olivier.
According to FAQ #2312, I generate a restrict_xxx.dat and set the masses to the benchmark points. Then the Lorentz invariance is conserved. If I remove the electron mass, the diagrams reduced to 8, I think it maybe the light fermion yukawa coupling is excluded?

Best wishes,
Halley

Revision history for this message
dfrg (brtggh) said :
#9

Fontmaker is the first font maker keyboard app for iPhone to create your own font with handwriting and use it as a keyboard in iMessage, Instagram, Snapchat, Tiktok, Facebook and more to chat with your friends! Use your own handwriting to chat with your friends to make it feel personal and intimate.
https://freedafonts.com/