Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coupling ordering issue? #862

Closed
valassi opened this issue Jun 4, 2024 · 5 comments · Fixed by #918
Closed

Coupling ordering issue? #862

valassi opened this issue Jun 4, 2024 · 5 comments · Fixed by #918
Assignees

Comments

@valassi
Copy link
Member

valassi commented Jun 4, 2024

Followup from today's discussion. While debugging #826 Olivier observed some coupling ordering issues
#826 (comment)

image

This might be the root cause of the zero cross section issue #826 (or maybe not)

Note: in any case this is unrelated to channel-iconfig mapping errors discussed in #826 and #852 and probably responsible for #845 and #856

@oliviermattelaer
Copy link
Member

@roiser
Did you check the real/imaginary ordering?

If yes then we can close this issue since the PR is in progress

@roiser
Copy link
Member

roiser commented Jul 19, 2024

Hi, I can confirm that its all correct for the independent couplings. I need to check for the running ones, cheers

@roiser
Copy link
Member

roiser commented Jul 22, 2024

Hi @oliviermattelaer, for after the vacation ;-), I checked the ordering of all the couplings and also the real/imaginary parts, this looks all correct. E.g. looking at the parameters as provided by Fortran (log file) those are

GC_10 =  -0.12781E+01   0.00000E+00
GC_11 =   0.00000E+00   0.12781E+01
GC_13 =   0.00000E+00   0.57824E-04
GC_40 =  -0.00000E+00  -0.28804E+00
GC_53 =  -0.00000E+00  -0.27437E-01
GC_74 =  -0.00000E+00  -0.17058E-01

checking their values as they arrive for the wavefunctions, those are

(gdb) print COUPs
$28 = {0x53ee580, 0x53ee5c0, 0x53ee600, 0x7ffff7f9adc0 <mg5amcCpu::cIPC>, 0x7ffff7f9add0 <mg5amcCpu::cIPC+16>, 0x7ffff7f9ade0 <mg5amcCpu::cIPC+32>}
(gdb) print *COUPs[0]@8 // --> GC_10
$30 = {-1.2458026581298607, -1.2458056165991431, -1.2458036092599556, -1.2458080782619843, 0, 0, 0, 0}
(gdb) print *COUPs[1]@8 // --> GC_11
$31 = {0, 0, 0, 0, 1.2458026581298607, 1.2458056165991431, 1.2458036092599556, 1.2458080782619843}
(gdb) print *COUPs[2]@8 // --> GC_13
$32 = {0, 0, 0, 0, 5.4935752179696128e-05, 5.493601309730976e-05, 5.4935836063073307e-05, 5.4936230200321482e-05}
(gdb) print *COUPs[3]@2 // --> GC_40
$34 = {-0, -0.28804415396362731}
(gdb) print *COUPs[4]@2 // --> GC_53
$35 = {-0, -0.027436627757416142}
(gdb) print *COUPs[5]@2 // --> GC_74
$36 = {-0, -0.017058022507245231}

NB: I'm not sure about the values in the log file above for GC_11/12/13, but I followed the calculation of those with the Gs in the debugger and this looks all correct, and especially about your question the real and imaginary parts of those are in the right order.

NB2: for checking this situation I created a process where madgraph gives me a mix of dependent and independent couplings as they appear in the model, i.e.

generate g g > h > b b~
add process q q > Z Z
add process g g > t t~ 

cheers Stefan

@valassi
Copy link
Member Author

valassi commented Jul 22, 2024

The specific issue 826 about a zero cross section in susy process is fixed by PR #918 (thanks @oliviermattelaer @roiser). Indeed it is caused by a couplings order #862, i.e. this bug.

Closing this as fixed by PR #918 (to be merged soon). Code regenerated in #934.

@valassi valassi closed this as completed Jul 22, 2024
@valassi valassi reopened this Jul 22, 2024
@valassi valassi linked a pull request Jul 22, 2024 that will close this issue
@valassi
Copy link
Member Author

valassi commented Jul 22, 2024

Attached to #918, reopened and closed again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants