MG Output Error for H > a a Reaction using @NLO Extension of Model SM

Bug #1955926 reported by Brian Keith Ragsdale
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Invalid
Undecided
Unassigned

Bug Description

Hello,

I used the archetypical SM.fr file to generate an FA folder (GEN, MOD, PARS) in FR to obtain CT and R terms with the goal of generating a UFO file for the SM@NLO. My model process to determine the success of that goal was the Decay Reaction Higgs to DiPhoton. Details of the computations are below, followed by the terminal log.

/////////////////////////////////////////////////////////////////////////////
**FeynArts**
(3.11)

**FeynRules**

(
Update notes for FeynRules 2.3.x

2642 2.3.47 25-05-21 fuks: Mathematica 12.2 and parallelisation are
                                 fixed
)

**MadGraph**
(
Update notes for MadGraph5_aMC@NLO (in reverse time order)

2.9.4(28/05/21)
)

**Mathematica**
(12.0)
/////////////////////////////////////////////////////////////////////////////

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Below is the terminal log with the error highlighted above and below by a series of '-' at the end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MG5_aMC>import model SMNLO122821/
INFO: load particles
INFO: load vertices
DEBUG: MG5 converter defines UUV3 to P(3,2) + P(3,3)
DEBUG: MG5 converter defines VVV10 to P(3,1)*Metric(1,2) + P(2,3)*Metric(1,3) + P(1,2)*Metric(2,3)
DEBUG: MG5 converter defines VVV11 to P(3,2)*Metric(1,2) + P(2,1)*Metric(1,3) + P(1,3)*Metric(2,3)
DEBUG: MG5 converter defines FFS4 to ProjM(2,1) + ProjP(2,1)
DEBUG: MG5 converter defines VVVV5 to Metric(1,4)*Metric(2,3) + Metric(1,3)*Metric(2,4)
DEBUG: MG5 converter defines VVVV6 to Metric(1,3)*Metric(2,4) + Metric(1,2)*Metric(3,4)
DEBUG: MG5 converter defines VVVV7 to Metric(1,4)*Metric(2,3) + Metric(1,3)*Metric(2,4) + Metric(1,2)*Metric(3,4)
DEBUG: MG5 converter defines VVVV8 to Metric(1,4)*Metric(2,3) + Metric(1,2)*Metric(3,4)
DEBUG: MG5 converter defines VVV12 to P(3,1)*Metric(1,2) + P(1,2)*Metric(2,3)
DEBUG: MG5 converter defines VVV13 to P(3,2)*Metric(1,2) + P(1,3)*Metric(2,3)
DEBUG: MG5 converter defines VVV14 to P(3,1)*Metric(1,2) + P(2,3)*Metric(1,3)
DEBUG: MG5 converter defines VVV15 to P(3,2)*Metric(1,2) + P(2,1)*Metric(1,3)
DEBUG: MG5 converter defines FFV4 to Gamma(3,2,-1)*ProjM(-1,1) + Gamma(3,2,-1)*ProjP(-1,1)
DEBUG: MG5 converter defines FF6 to ProjM(2,1) + ProjP(2,1)
DEBUG: MG5 converter defines FF7 to P(-1,1)*Gamma(-1,2,-2)*ProjM(-2,1) + P(-1,1)*Gamma(-1,2,-2)*ProjP(-2,1)
DEBUG: MG5 converter defines VVV16 to P(2,1)*Metric(1,3) + P(1,2)*Metric(2,3)
DEBUG: MG5 converter defines VVV17 to P(2,3)*Metric(1,3) + P(1,2)*Metric(2,3)
DEBUG: model prefixing takes 5.1495606899261475
This model does not allow Feynman gauge. You will only be able to do tree level QCD loop cmputations with it.
INFO: Change particles name to pass to MG5 convention
Kept definitions of multiparticles p / j / l+ / l- / vl / vl~ unchanged
Defined multiparticle all = g ghg ghg~ u c d s u~ c~ d~ s~ a gha gha~ ve vm vt e- mu- ve~ vm~ vt~ e+ mu+ t b t~ b~ z w+ ghz ghwp ghwm h w- ghz~ ghwp~ ghwm~ ta- ta+
MG5_aMC>generate h > a a [noborn = QED]
You will only be able to do tree level and QCD corrections with this model because it does not support Feynman gauge.
DEBUG: Generating process: h > a a [ noborn = QED ]
DEBUG: Born diagrams generation skipped by user request.
DEBUG: Coupling order combinations considered: (QCD,QED,WEIGHTED)
DEBUG: > No Born contributions for this process.
DEBUG: > loop : (0,6,W12)
INFO: Contributing diagrams generated: 0 Born, 9 loops, 4 R2, 1 UV
1 processes with 9 diagrams generated in 0.241 s
Total: 1 processes with 9 diagrams
MG5_aMC>output haa122821
INFO: initialize a new directory: haa122821
INFO: remove old information in haa122821
INFO: Organizing processes into subprocess groups
INFO: Generating Helas calls for process: h > a a [ noborn = QED ]
DEBUG: 1 loop wavefunctions have been reused, for a total of 25 ones
DEBUG: Computing the loop color basis
INFO: Processing color information for loop process: h > a a [ noborn = QED ]
INFO: Creating color matrix loop process: h > a a [ noborn = QED ]
INFO: Creating files in directory /home/bandit5/maddev/mg5amcnlo/LTS_dev/haa122821/SubProcesses/PV0_0_1_h_aa
DEBUG: adding in aloha model 17 lorentz struct
ALOHA: aloha creates VVS1 set of routines with options: L2
ALOHA: aloha creates FFV1 set of routines with options: L1
INFO: Computing diagram color coefficients
INFO: Drawing loop Feynman diagrams for Process: h > a a [ noborn = QED ]
INFO: Creating files in directory P0_h_aa
INFO: Generating Feynman diagrams for Process: h > a a [ noborn = QED ]
INFO: Finding symmetric diagrams for subprocess group h_aa
Generated helas calls for 1 subprocesses (9 diagrams) in 0.074 s
------------------------------------------------------------------------------
Command "output haa122821" interrupted with error:
TypeError : '<=' not supported between instances of 'int' and 'complex'
Please report this bug on https://bugs.launchpad.net/mg5amcnlo
More information is found in 'MG5_debug'.
Please attach this file to your report.
------------------------------------------------------------------------------

Revision history for this message
Brian Keith Ragsdale (bransbrain) wrote :
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

HI,

I do not have a mathematica license, neither the knowledge of FeynRules/Feynarts to help you.
However if you provide your UFO model, I can try to reproduce your issue on my system and see if the issue is inside your model or an issue within MG5aMC.
In the first case, I might be able to give you hint of the issue, in the second, I might be able to provide a patch.

Cheers,

Olivier

Revision history for this message
Brian Keith Ragsdale (bransbrain) wrote :

Nice to hear from you Olivier,

I hope you can access the UFO folder from my drive. Here's the link: https://drive.google.com/drive/folders/1JYjoBHBmpxRQnOxq8ZBl7V7HQBtIzHcf?usp=sharing

I'm looking forward to your response!

Regards.
Brian Keith Ragsdale II

P.S. I've been enjoying yours and other's work in the Tutorials and Help directory on the MadGraph website. So amazed by everyone's work and have myself a nice collection of reading materials for the next few days while I'm out of the office. Cheers!

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote : Re: [Bug 1955926] MG Output Error for H > a a Reaction using @NLO Extension of Model SM
Download full text (8.3 KiB)

Hi,

So the problem is within this expression:

I execute UVGC_153_116 = ( ( ( 0 if mdl_MW==0 else (mdl_ee__exp__4*mdl_complexi*mdl_vev__exp__2)/(16.*cmath.pi**2*mdl_MW__exp__2*mdl_sw__exp__4) - (mdl_ee__exp__4*mdl_complexi*mdl_vev__exp__2)/(24.*cmath.pi*mdl_MW__exp__2*mdl_sw__exp__4*mdl_sqrt__3) ) if mdl_MH==mdl_MW else ( 0 if mdl_MW==0 else ( 0 if mdl_MH__exp__2<=4*mdl_MW__exp__2 else -(mdl_ee__exp__4*mdl_complexi*mdl_MW__exp__2*mdl_vev__exp__2*reglog(-(mdl_MU_R__exp__2*(-(mdl_MH__exp__2/mdl_MU_R__exp__2) + (2*mdl_MW__exp__2)/mdl_MU_R__exp__2 + (mdl_MH*cmath.sqrt(mdl_MH__exp__2/mdl_MU_R__exp__2 - (4*mdl_MW__exp__2)/mdl_MU_R__exp__2))/MU_R))/(2.*mdl_MW__exp__2)))/(8.*MU_R*cmath.pi**2*mdl_MH__exp__3*mdl_sw__exp__4*cmath.sqrt(mdl_MH__exp__2/mdl_MU_R__exp__2 - (4*mdl_MW__exp__2)/mdl_MU_R__exp__2)) ) + ( -(mdl_ee__exp__4*mdl_complexi*mdl_MW__exp__2*mdl_vev__exp__2*reglog((mdl_MU_R__exp__2*(-(mdl_MH__exp__2/mdl_MU_R__exp__2) + (2*mdl_MW__exp__2)/mdl_MU_R__exp__2 + (mdl_MH*cmath.sqrt(mdl_MH__exp__2/mdl_MU_R__exp__2 - (4*mdl_MW__exp__2)/mdl_MU_R__exp__2))/MU_R))/(2.*mdl_MW__exp__2)))/(8.*MU_R*cmath.pi**2*mdl_MH__exp__3*mdl_sw__exp__4*cmath.sqrt(mdl_MH__exp__2/mdl_MU_R__exp__2 - (4*mdl_MW__exp__2)/mdl_MU_R__exp__2)) if mdl_MH__exp__2<4*mdl_MW__exp__2 else 0 ) + (mdl_ee__exp__4*mdl_complexi*mdl_vev__exp__2)/(16.*cmath.pi**2*mdl_MH__exp__2*mdl_sw__exp__4) ) + ( ( 0 if mdl_MW==0 else (mdl_ee__exp__4*mdl_complexi*mdl_vev__exp__2)/(16.*cmath.pi**2*mdl_MH__exp__2*mdl_sw__exp__4) ) if mdl_MH__exp__2==4*mdl_MW__exp__2 else 0 ) ) + ( (mdl_ee__exp__4*mdl_complexi*mdl_vev__exp__2)/(16.*cmath.pi**2*mdl_MH__exp__2*mdl_sw__exp__4) if mdl_MW==0 else 0 ) if mdl_MH else ( 0 if mdl_MW==0 else -(mdl_ee__exp__4*mdl_complexi*mdl_vev__exp__2)/(96.*cmath.pi**2*mdl_MW__exp__2*mdl_sw__exp__4) ) )

given the error, the issue is within the sub-expression
 mdl_MH__exp__2<=4*mdl_MW__exp__2

So it seems that your W mass is complex and not real.
Do you use some kind of complex mass-scheme or is your benchmark not setup correctly?

Cheers,

Olivier

> On 29 Dec 2021, at 00:37, Brian Keith Ragsdale <email address hidden> wrote:
>
> Nice to hear from you Olivier,
>
> I hope you can access the UFO folder from my drive. Here's the link:
> https://drive.google.com/drive/folders/1JYjoBHBmpxRQnOxq8ZBl7V7HQBtIzHcf?usp=sharing
>
> I'm looking forward to your response!
>
> Regards.
> Brian Keith Ragsdale II
>
> P.S. I've been enjoying yours and other's work in the Tutorials and Help
> directory on the MadGraph website. So amazed by everyone's work and have
> myself a nice collection of reading materials for the next few days
> while I'm out of the office. Cheers!
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1955926
>
> Title:
> MG Output Error for H > a a Reaction using @NLO Extension of Model SM
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hello,
>
> I used the archetypical SM.fr file to generate an FA folder (GEN, MOD,
> PARS) in FR to obtain CT and R terms with the goal of generating a UFO
> file for the SM@NLO. My model process to determine the success of that
> ...

Read more...

Revision history for this message
Brian Keith Ragsdale (bransbrain) wrote (last edit ):

Hello,

This Update Contains Nothing Substantive and Serves Only as a Ping to Inform Olivier the Debug is in Progress.

It would certainly be a mistake for the W mass to be Complex if in the canonical files the W mass is intended to be Real and remain Real after the NLO process using only the OnShellRenormalized SM lagrangian FA output files from Feynarts and the subsequent .nlo output file from FA in FR to produce a UFO file @ NLO.
  That said, my interpretation of Measurable quantities is they are Real. I assume something is incorrect in my benchmark, the way I produced the UFO folder file. It would be a joy to message the people over at FeynRules but it seems they no longer offer such service.
  I tried one curiosity that led to more strife. Need something I can identify to motivate the debug. I'll compare the files within my UFO with the files in a stable SM@NLO UFO folder file such as loop_qcd_qed_sm and will respond if anything seems culprit or helpful regarding the Complex mass.

Regards.
Brian Keith Ragsdale II

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :
Download full text (7.6 KiB)

Hi,

The complex mass scheme is a vey common framework to set all masses as complex parameter which allows to have non zero width for massive particles and still preserve the gauge invariance of the theory.

But if you can use a zero width scheme or a fix width scheme and if your mass are such that the formula for the W mass is indeed real, then the best is to take the real part of the W mass for this check:

MW = Parameter(name = 'MW',
        nature = 'internal',
               type = 'real',
        value = 're(cmath.sqrt(MZ**2/2. + cmath.sqrt(MZ**4/4. - (aEW*cmath.pi*MZ**2)/(Gf*cmath.sqrt(2)))))',
               texname = 'M_W')

The issue might be a pure python issue since cmath can sometimes return complex number even when not needed.
(this is the issue of python language)

Cheers,

Olivier

> On 3 Jan 2022, at 20:19, Brian Keith Ragsdale <email address hidden> wrote:
>
> Hello,
>
> This Update Contains Nothing Substantive and Serves Only as a Ping to
> Inform Olivier the Debug is in Progress.
>
> It would certainly be a mistake for the W mass to be Complex if in the canonical files the W mass is intended to be Real and remain Real after the NLO process using only the OnShellRenormalized SM lagrangian FA output files from Feynarts and the subsequent .nlo output file from FA in FR to produce a UFO file @ NLO.
> That said, my interpretation of Measurable quantities is they are Real. I assume something is incorrect in my benchmark, the way I produced the UFO folder file. It would be a joy to message the people over at FeynRules but it seems they no longer offer such service.
> I tried one curiosity that led to more strife. Need something I can identify to motivate the debug. I'll compare the files within my UFO with the files in a stable SM@NLO UFO folder file such as loop_qcd_qed_sm and will respond if anything seems culprit or helpful regarding the Complex mass.
>
> Regards.
> Brian Keith Ragsdale II
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1955926
>
> Title:
> MG Output Error for H > a a Reaction using @NLO Extension of Model SM
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Hello,
>
> I used the archetypical SM.fr file to generate an FA folder (GEN, MOD,
> PARS) in FR to obtain CT and R terms with the goal of generating a UFO
> file for the SM@NLO. My model process to determine the success of that
> goal was the Decay Reaction Higgs to DiPhoton. Details of the
> computations are below, followed by the terminal log.
>
> /////////////////////////////////////////////////////////////////////////////
> **FeynArts**
> (3.11)
>
> **FeynRules**
>
> (
> Update notes for FeynRules 2.3.x
>
> 2642 2.3.47 25-05-21 fuks: Mathematica 12.2 and parallelisation are
> fixed
> )
>
> **MadGraph**
> (
> Update notes for MadGraph5_aMC@NLO (in reverse time order)
>
> 2.9.4(28/05/21)
> )
>
> **Mathematica**
> (12.0)
> /////////////////////////////////////////////////////////////////////////////
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~...

Read more...

Revision history for this message
Brian Keith Ragsdale (bransbrain) wrote :
Download full text (3.2 KiB)

Olivier,

Since I have no tools at my disposal, please follow the [square brackets] and underlying {curly brackets} for a logical shortcut. It begins at the arrow three lines above the third paragraph (if this structure, the one below, and that following beginning with "[First]" are defined paragraphs).

I hope your time has been well since we last spoke earlier this month. Preparing for the school semester, grabbing international students from the airport, and struggling with this debug are among the things that had me distracted recently; but I'm happy to say progress has been made on this issue. I will be pursuing this problem until it is resolved, posting the progress on this forum so others may consider our discussion regarding their own difficulties.
  --->[Here's the concise update]. I'll say what actions resolved which problems before speaking on the new challenges.

[First]
The solution that yielded momentum was as you suggested in your most recent contribution to this issue -- it seems cmath was returning a complex number. After demanding the value of the W mass to be real, MadGraph was able to yield a more proper output and even launched the decay reaction Higgs to diphoton with some success. Fortunately, the real problem has been uprooted.

{Due to the length of code} and my own inexperience on communicating these issues, {I have made a couple notes} in Evernote and will link them below. The {first note is the terminal log} containing our triumph, evidence that your technical conjecture was correct; the {second note} contains pointers to the new problem and in fact {is the bug report} generated by MadGraph after failing to launch the decay reaction of interest. If it is preferred, I will post the direct text of these documents on the forum by comment.

{First Note; Terminal Log}: https://www.evernote.com/shard/s497/sh/6d5d3187-f003-4bd0-eddb-0754d48439f4/aeee09607a5850cecd40e0d22df7e83c

{Second Note; Bug Report}: https://www.evernote.com/shard/s497/sh/aebe11fd-2abd-a984-ced4-216d1436d95b/02e94721915eded452f4f9290919bef3

[Second]
This is where the project is stuck. I've reserved the majority of Sunday's time to investigate the issue and hope to have something substantial or useful to report in the next 12H, before 8pm Central Time. Before this submission and my merry way, I want to jot a last thing regarding the two linked notes.

--------------------

* [The second note] was pasted and left in the [original form]. Black text.
* [The first note], due to its length and courtesy, [has been altered] in form in three ways.

1) [Terminal lines that require input] from a user have been left unaltered, but I decided to [add bullets] to these lines. I hope it gives them more depth.

2) [Terminal lines that are generated automatically], via itself or by the contents therein, have been altered in color to help the reader. The change was [Black -> Green].

3) [Terminal lines with some auto-generated error] have been altered twofold. I will simply list the changes below.
3.1) Text color: [Black -> Red]
3.2) Text formatting: [Indention from LHS].

Thanks so much Olivier. I'm wont to speak too much and same goes for my writing; I simply ...

Read more...

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

So the problem seems to be that the "loop" block is missing.
That block should contains the mur parameter such that the dependence in the renormalisation scale can be include in R2 and counter-term of the loop.

Cheers,

Olivier

Changed in mg5amcnlo:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.