MadGraph5_aMC@NLO

Madgraph stuck after launch of a NLO process

Asked by Esteban Chalbaud

Dear all,

I am having problems in running Madgraph at NLO for a process of the form:

generate p p > t t~ y1 [QCD]

Using a model called DMsimp_s_spin1 (https://feynrules.irmp.ucl.ac.be/wiki/DMsimp)

But when I launch the process, there is a warning and Madgraph simply gets stuck for hours:

WARNING: program /lstore/titan/atlas/emogollon/MG5_aMC_v2_9_14/bin/teste_nlo/SubProcesses/P0_dbx_y1ttx/ajob1 1 F 0 0 launch ends with non zero status: 1. Stop all computation
INFO: Idle: 29, Running: 7, Completed: 16 [ 2m 24s ]
INFO: Idle: 29, Running: 6, Completed: 17 [ 2m 24s ]
INFO: Idle: 29, Running: 5, Completed: 18 [ 2m 24s ]
INFO: Idle: 29, Running: 4, Completed: 19 [ 2m 24s ]
INFO: Idle: 29, Running: 3, Completed: 20 [ 2m 24s ]
INFO: Idle: 29, Running: 2, Completed: 21 [ 2m 24s ]
INFO: Idle: 29, Running: 0, Completed: 23 [ 2m 24s ]

Is there any place inside Madgraph where I can check what is going on?

Best,
Esteban

Question information

Language:
English Edit question
Status:
Answered
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

You can check the directory
/lstore/titan/atlas/emogollon/MG5_aMC_v2_9_14/bin/teste_nlo/SubProcesses/P0_dbx_y1ttx/

inside you should have a directory GF1_all (or all_GF1) which should have a log file with usefull information on the issue.

Cheers,

Olivier

> On 17 Mar 2023, at 18:35, Esteban Chalbaud <email address hidden> wrote:
>
> /lstore/titan/atlas/emogollon/MG5_aMC_v2_9_14/bin/teste_nlo/SubProcesses/P0_dbx_y1ttx/

Revision history for this message
Esteban Chalbaud (echalbau) said : 		#2

Ok, I have checked the directory and there is this file called log_MINT0.txt, and at the end, there is this phrase:
.
.
.
muR_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state
 muF1_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state
 muF2_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state
 QES_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state

 alpha_s= 9.1078504934219512E-002
 ERROR: INTEGRAL APPEARS TO BE ZERO.
 TRIED 100800 PS POINTS AND ONLY 0 GAVE A NON-ZERO INTEGRAND.

In contrast, I have checked in another NLO process (with the sm model) and I have this:

 muF1_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state
 muF2_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state
 QES_reference [functional form]:
    H_T/2 := sum_i mT(i)/2, i=final state

 alpha_s= 9.9819464364791610E-002
 BORN: keeping split order 1
 counterterm S.O 1 QCD
 BORN: keeping split order 1
 counterterm S.O 2 QED
 BORN: not keeping split order 1
 Charge-linked born are not used
 Color-linked born are used
 alpha_s value used for the virtuals is (for the first PS point): 9.9819464364791610E-002

After that I get into the MadLoop, using the sm model, why this is happening alpha s is not the problem right?

Best Esteban

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

Do you have coupling which are zero for your benchmark?
If you do you will get such issue.
You can use a restricted model to avoid such issue.

Cheers,

Olivier

> On 18 Mar 2023, at 10:20, Esteban Chalbaud <email address hidden> wrote:
>
> Question #705868 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/705868
>
> Esteban Chalbaud posted a new comment:
> Ok, I have checked the directory and there is this file called log_MINT0.txt, and at the end, there is this phrase:
> .
> .
> .
> muR_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
> muF1_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
> muF2_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
> QES_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
>
> alpha_s= 9.1078504934219512E-002
> ERROR: INTEGRAL APPEARS TO BE ZERO.
> TRIED 100800 PS POINTS AND ONLY 0 GAVE A NON-ZERO INTEGRAND.
>
>
> In contrast, I have checked in another NLO process (with the sm model) and I have this:
>
>
> muF1_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
> muF2_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
> QES_reference [functional form]:
> H_T/2 := sum_i mT(i)/2, i=final state
>
> alpha_s= 9.9819464364791610E-002
> BORN: keeping split order 1
> counterterm S.O 1 QCD
> BORN: keeping split order 1
> counterterm S.O 2 QED
> BORN: not keeping split order 1
> Charge-linked born are not used
> Color-linked born are used
> alpha_s value used for the virtuals is (for the first PS point): 9.9819464364791610E-002
>
> After that I get into the MadLoop, using the sm model, why this is
> happening alpha s is not the problem right?
>
> Best Esteban
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Esteban Chalbaud (echalbau) said : 		#4

I am basically running the default card of the model:

######################################################################
## PARAM_CARD AUTOMATICALY GENERATED BY MG5 FOLLOWING UFO MODEL ####
######################################################################
## ##
## Width set on Auto will be computed following the information ##
## present in the decay.py files of the model. ##
## See arXiv:1402.1178 for more details. ##
## ##
######################################################################

###################################
## INFORMATION FOR CKMBLOCK
###################################
Block ckmblock
    1 2.277360e-01 # cabi

###################################
## INFORMATION FOR DMINPUTS
###################################
Block dminputs
    1 0.000000e+00 # gVXc
    2 1.000000e+00 # gVXd
    3 0.000000e+00 # gAXd
    4 2.500000e-01 # gVd11
    5 2.500000e-01 # gVu11
    6 2.500000e-01 # gVd22
    7 2.500000e-01 # gVu22
    8 2.500000e-01 # gVd33
    9 2.500000e-01 # gVu33
   10 0.000000e+00 # gVl11
   11 0.000000e+00 # gVl22
   12 0.000000e+00 # gVl33
   13 0.000000e+00 # gAd11
   14 0.000000e+00 # gAu11
   15 0.000000e+00 # gAd22
   16 0.000000e+00 # gAu22
   17 0.000000e+00 # gAd33
   18 0.000000e+00 # gAu33
   19 0.000000e+00 # gAl11
   20 0.000000e+00 # gAl22
   21 0.000000e+00 # gAl33
   22 0.000000e+00 # gnu11
   23 0.000000e+00 # gnu22
   24 0.000000e+00 # gnu33
   25 0.000000e+00 # gVu31
   26 0.000000e+00 # gAu31
   27 0.000000e+00 # gVd31
   28 0.000000e+00 # gAd31
   29 0.000000e+00 # gVh

###################################
## INFORMATION FOR MASS
###################################
Block mass
    6 1.720000e+02 # MT
   15 1.777000e+00 # MTA
   23 9.118760e+01 # MZ
   25 1.250000e+02 # MH
  5000001 1.000000e+03 # MY1
  5000511 1.000000e+01 # MXr
  5000512 1.000000e+01 # MXc
  5000521 1.000000e+01 # MXd
## Dependent parameters, given by model restrictions.
## Those values should be edited following the
## analytical expression. MG5 ignores those values
## but they are important for interfacing the output of MG5
## to external program such as Pythia.
  1 0.000000e+00 # d : 0.0
  2 0.000000e+00 # u : 0.0
  3 0.000000e+00 # s : 0.0
  4 0.000000e+00 # c : 0.0
  5 0.000000e+00 # b : 0.0
  11 0.000000e+00 # e- : 0.0
  12 0.000000e+00 # ve : 0.0
  13 0.000000e+00 # mu- : 0.0
  14 0.000000e+00 # vm : 0.0
  16 0.000000e+00 # vt : 0.0
  21 0.000000e+00 # g : 0.0
  22 0.000000e+00 # a : 0.0
  24 7.982436e+01 # w+ : cmath.sqrt(MZ__exp__2/2. + cmath.sqrt(MZ__exp__4/4. - (aEW*cmath.pi*MZ__exp__2)/(Gf*sqrt__2)))
  9000002 9.118760e+01 # ghz : MZ
  9000003 7.982436e+01 # ghwp : MW
  9000004 7.982436e+01 # ghwm : MW

###################################
## INFORMATION FOR SMINPUTS
###################################
Block sminputs
    1 1.279000e+02 # aEWM1
    2 1.166370e-05 # Gf
    3 1.184000e-01 # aS (Note that Parameter not used if you use a PDF set)

###################################
## INFORMATION FOR YUKAWA
###################################
Block yukawa
    6 1.720000e+02 # ymt
   15 1.777000e+00 # ymtau

###################################
## INFORMATION FOR DECAY
###################################
DECAY 6 1.508336e+00 # WT
DECAY 23 2.495200e+00 # WZ
DECAY 24 2.085000e+00 # WW
DECAY 25 4.070000e-03 # WH
DECAY 5000001 1.000000e+01 # WY1
## Dependent parameters, given by model restrictions.
## Those values should be edited following the
## analytical expression. MG5 ignores those values
## but they are important for interfacing the output of MG5
## to external program such as Pythia.
DECAY 1 0.000000e+00 # d : 0.0
DECAY 2 0.000000e+00 # u : 0.0
DECAY 3 0.000000e+00 # s : 0.0
DECAY 4 0.000000e+00 # c : 0.0
DECAY 5 0.000000e+00 # b : 0.0
DECAY 11 0.000000e+00 # e- : 0.0
DECAY 12 0.000000e+00 # ve : 0.0
DECAY 13 0.000000e+00 # mu- : 0.0
DECAY 14 0.000000e+00 # vm : 0.0
DECAY 15 0.000000e+00 # ta- : 0.0
DECAY 16 0.000000e+00 # vt : 0.0
DECAY 21 0.000000e+00 # g : 0.0
DECAY 22 0.000000e+00 # a : 0.0
DECAY 5000511 0.000000e+00 # xr : 0.0
DECAY 5000512 0.000000e+00 # xc : 0.0
DECAY 5000521 0.000000e+00 # xd : 0.0
DECAY 9000002 2.495200e+00 # ghz : WZ
DECAY 9000003 2.085000e+00 # ghwp : WW
DECAY 9000004 2.085000e+00 # ghwm : WW
#===========================================================
# QUANTUM NUMBERS OF NEW STATE(S) (NON SM PDG CODE)
#===========================================================

Block QNUMBERS 9000001 # gha
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 9000002 # ghz
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 9000003 # ghwp
        1 3 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 9000004 # ghwm
        1 -3 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 82 # ghg
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 8 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 5000511 # xr
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 0 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 5000512 # xc
        1 0 # 3 times electric charge
        2 1 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 5000521 # xd
        1 0 # 3 times electric charge
        2 2 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 1 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 5000001 # y1
        1 0 # 3 times electric charge
        2 3 # number of spin states (2S+1)
        3 1 # colour rep (1: singlet, 3: triplet, 8: octet)
        4 0 # Particle/Antiparticle distinction (0=own anti)

And it is still not working.
Best
Esteban

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

So yes, you do have a LOT of zero in your benchmark point.
I would suggest to follow the advise of the FAQ to remove all those zero from the model, such that MG5aMC can know from the beginning what is zero and will not complain that part of the computation is zero.

Cheers,

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

Can you help with this problem?

Provide an answer of your own, or ask Esteban Chalbaud for more information if necessary.

To post a message you must log in.