test failure and wrong born in MG5

Bug #1694548 reported by Satyajit Seth
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Fix Released
Undecided
Rikkert Frederix

Bug Description

Dear Developers,

In a model with two leptoquarks ("lqvu" and "lqvd") that are basically considered as colour-triplet heavy vector bosons, I find that while generating the process: p p > lqvu lqvu~ [real=QCD], some soft tests fail and those are basically associated with the FKS configurations containing gluon and leptoquark (debug.log file is attached).

Would you please look into the issue and let me know what is to be done to get all tests passed? - the UFO model file is attached herewith.

Now, if I set "max_fail" value high enough (say 1.1) in the code responsible for test_ME and/or test_MC just to forcefully pass all the tests, I eventually get all the values for born, single and double poles. However, I find that few born values (very small ones with E-004) do not match with the following analytical expression:

-1/72 * 1/mLQ^2 * 1/s12^2 * (CA^2 - 1) * gs^4 * (16*mLQ^6 - 2*mLQ^4*(s13 + s23) + (s13 + s23)*(s13^2 + s23^2) - 2* mLQ^2*(s13^2 + 6*s13*s23 + s23^2))

What could be the reason of such mismatch between MG5 result and the analytical expression? - the "log.txt" file (of the directory P0_uux_lqvulqvux) is attached herewith. The process was generated with quark flavour no. nf=4.

Finally, on what I am more concerned about is the (single) pole value. Is it possible that MadFKS may produce wrong poles when ME/MC test fails and/or while setting "max_fail" value as high as 1.10? Basically, MadFKS double pole looks perfectly fine and it does match with the virtual part that has been calculated analytically; however the single pole does not.

It would be very much helpful if you please comment on the above points.

Best regards,
Satyajit

Revision history for this message
Satyajit Seth (sseth) wrote :
Changed in mg5amcnlo:
assignee: nobody → Rikkert Frederix (frederix)
Revision history for this message
Rikkert Frederix (frederix) wrote :

Dear Satyajit,

Does your model work correctly at LO? I.e., with

generate p p > lqvu lqvu~

and

generate p p > lqvu lqvu~ j

?

Best,
Rikkert

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

Both the processes you mentioned are working well under LO; no interruption is occurred there.

Best regards,
Satyajit

Revision history for this message
Rikkert Frederix (frederix) wrote :

But are the results correct? Do the matrix elements agree with your analytic formulas?

Rikkert

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

I find that, at LO, the MG5 result for p p > lqvu lqvu~ perfectly matches with the analytical one, even for smaller values (with E-004). However, I don't have the analytical expression for the process with extra jet at this moment. But it seems LO would be okay with this model.

Regards,
Satyajit

Revision history for this message
Rikkert Frederix (frederix) wrote :

Dear Satyajit,

I'm confused. The LO and NLO versions of the code use EXACTLY the same Born matrix elements. Hence, I don't understand how one can agree with the analytic expression and the other not. B.t.w., what do you mean by "few born values (very small ones with E-004)" ? The matrix elements are dimensionfull quantities. Do you mean a relative accuracy?

Best,
Rikkert

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

Exactly, this is very strange. That is why I wonder whether it has something to do with the test failures that I'm bypassing with an outrageous value of max_fail.

By very small born values, I mean to indicate those |M|^2 values which are quite small in magnitude, for example, BORN = 8.3682093058915863E-004. Now, if you look into the log.txt file that I attached earlier and search this born value, you'll find that all the associated parameters listed there (with mLQ = 750 GeV) would not produce the same result what is expected from the analytical expression. However, this is not the case if you take any other higher born values; for those, the numerical result of MG5 and the one coming from the analytical calculation agree at least up to 12 places after the decimal point.

Because of this, I want to check whether the issue persists once it passes all tests with the default (or meaningful) value of max_fail parameter - but, I'm not able to do that as some FKS configurations with gluon and leptoquark stops the code to run.

Best regards,
Satyajit

Revision history for this message
Rikkert Frederix (frederix) wrote :

Dear Satyajit,

Ok. I found a problem with the code. It's very deep in the code, so it took quite some time to figure it out and make sure it's okay. I've attached a patch for this bug.

Anyway, thanks for posting this!

Best,
Rikkert

Changed in mg5amcnlo:
status: New → Fix Committed
Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

Many thanks for the fix.

Just want to check with you whether or not any (similar) kind of modification is required in those parts responsible for the pole (mainly, single pole) calculation.

Best regards,
Satyajit

Revision history for this message
Rikkert Frederix (frederix) wrote :

I believe this fixed also a problem in the single (and double) poles. So they should be correct now. Although, there can always be other bugs in the code...

Best,
Rikkert

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

The double pole is perfect throughout. However, it seems that MadFKS single pole is not correct, because:
(i) it is of wrong sign for some phase space points
(ii) it does not agree with MadLoop single pole (value of MadLoop single pole seems to be right as it is pretty close to my analytical result)

The output of check_poles (here, all the pole values are divided by born and alpha_s/2/pi) and the NLO UFO model are attached herewith.

Best regards,
Satyajit

Revision history for this message
Rikkert Frederix (frederix) wrote :

Dear Satyajit,

I can't find the problem. Can you confirm that your single pole is equal to what's in appendix B of https://arxiv.org/pdf/0908.4272.pdf ?

Best,
Rikkert

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

Thank you for the reference. I'll check whether my single pole reduces to the same form given there. Btw, I have checked that my single pole is in agreement with what is coming from MadLoop - is it possible that MadLoop might not follow the same single pole structure for certain conditions?

Best regards,
Satyajit

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

I find that my single poles are close (although not exactly same) to what is expected from eq. (B.2) of arxiv:0908.4272. However, MadFKS pole does not match with eq. (B.2) and also the sign between them differs. Just for a quick comparison (s13 = -5779126.0393483751; s23 = -2095873.9606515104; gs = 1.2197779637049220; MU_R = 1500):

single pole from eq. (B.2): -3.55988
single pole from my formula: -3.62293
single pole from MadFKS: +1.20105

Could the problem be something related to the colour of the charged vector boson? Also, would you please check and confirm whether MadLoop provides the correct single pole for a process involving charged & coloured vector bosons? In case you need, the NLO UFO model can be found in the attachment of my previous post.

Best regards,
Satyajit

Revision history for this message
Rikkert Frederix (frederix) wrote :

Dear Satyajit,

I don't know if the MadLoop single pole is correct; it depends if the model is implemented correctly. There is, a priori, no reason why it should not work.

What's in appendix B of https://arxiv.org/pdf/0908.4272.pdf is what's implemented in the code. I thought you had your own analytic expression for the single pole and could therefore compare analytically, not numerically. Are you saying that something is missing in eq. B.2? what could it be?

Best,
Rikkert

Revision history for this message
Satyajit Seth (sseth) wrote :

Dear Rikkert,

I don't know if anything is missing in eq. B.2. Basically, in my expression I used some numerical results in the intermediate stages to make the calculation faster. Anyway, I'll check if I could pinpoint the problem. Thanks a lot for all your inputs!

Best regards,
Satyajit

Changed in mg5amcnlo:
status: Fix Committed → Fix Released
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.