Cross section calculation comparison between MG4 and MG5 v1.5.7

I forgot to say that I have the model in FeynRules, so I calculated the cross sections in MG4 with the output generated for this package. Then I calculated the same cross sections but with the UFO output in MG5. Not sure this has something to do with my question.

Hi Jose,

In Fact the FR code didn't support anymore the output to the model format compatible with v4.
So this might be the problem. Also the v4 format doesn't support arbitrary lorentz structure.
I'm not 100% sure but I think that FR removes the interactions not supported by the v4 format.
If this is the case, you should notice that you have more interaction in the UFO model than in the v4 model.

Did you check using the v4 model with MG5 and see with which one you have an agreement?
Did you check the validity of the UFO model for the process where you observe difference?
(with the command check for example check p p > w+ j )

In doubt, could you send me the model by email? (<email address hidden>) [both UFO and v4 model]
As well as the Cards (proc_card/param_card/run_card/...) information.
Such that I can check myself if this is a MG5 bug or a one related to the model.

Cheers,

Olivier

On Feb 27, 2013, at 11:41 AM, Jose Daivd Ruiz Alvarez <email address hidden> wrote:

> Question #222983 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/222983
>
> Jose Daivd Ruiz Alvarez posted a new comment:
> I forgot to say that I have the model in FeynRules, so I calculated the
> cross sections in MG4 with the output generated for this package. Then I
> calculated the same cross sections but with the UFO output in MG5. Not
> sure this has something to do with my question.
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Hi Jose,

Thanks for the files.
I've try to use the v4 model in MG5 and a lot of warning are raised in MG5 for this v4 model.
The reason is that the file interactions.dat is not correctly formatted:
For example:
hn1 ve ha0 MGVX25
didn't contain order information.

Therefore, I think that it's better to not use this output of FR at all.

Cheers,

Olivier

Hi Olivier,

Yes, I've seen this. But what I did was to use the v4 files in MG4 and UFO files in MG5. They came from same FR implementation, and I correctly obtained the cross sections with my implementation with v4 on MG4 accordingly to a paper that had done the same thing. So what is wierd is that I'm sure my implementation is correct and works with MG4, but when I use the same implementation to obtain a UFO version and calculate the cross sections with MG5 I do not obtain the same.

Thanks,
Jose
________________________________________
From: <email address hidden> [<email address hidden>] on behalf of Olivier Mattelaer [<email address hidden>]
Sent: 28 February 2013 18:01
To: Jose David Ruiz Alvarez
Subject: Re: [Question #222983]: Cross section calculation comparison between MG4 and MG5 v1.5.7

Your question #222983 on MadGraph5 changed:
https://answers.launchpad.net/madgraph5/+question/222983

Olivier Mattelaer proposed the following answer:
Hi Jose,

Thanks for the files.
I've try to use the v4 model in MG5 and a lot of warning are raised in MG5 for this v4 model.
The reason is that the file interactions.dat is not correctly formatted:
For example:
hn1 ve ha0 MGVX25
didn't contain order information.

Therefore, I think that it's better to not use this output of FR at all.

Cheers,

Olivier

--
If this answers your question, please go to the following page to let us
know that it is solved:
https://answers.launchpad.net/madgraph5/+question/222983/+confirm?answer_id=2

If you still need help, you can reply to this email or go to the
following page to enter your feedback:
https://answers.launchpad.net/madgraph5/+question/222983

You received this question notification because you asked the question.

Hi Jose,

Do you mean that the v4 model is in agreement to an analytical formula?
If not, I'm not worry.
You are using
1) a functionality which is not supported anymore in FR.
2) the output of this code is clearly not valid.
3) you use MG4 which is as well not supported anymore.

One possibility is to check against other generator.
For this the following web site can help you:
http://feynrules.irmp.ucl.ac.be/validation
If you have problem with it, please ask Neil Christensen.

Cheers,

Olivier

Hi Olivier,

After doing some checks on my model I have now a FR version that produces a v4 output that can be read by MG5 without warning or problems. I only have to change the compiler in the makefile of Source/MODEL of the working directory for the process. But I'm obtaining exactly the same problem described in https://bugs.launchpad.net/madgraph5/+bug/1095603

Error detected in "generate_events -f"
write debug file /afs/in2p3.fr/home/r/ruizalva/public/MadGraph5_v1_5_7/SA_v4/run_01_tag_1_debug.log
If you need help with this issue please contact us on https://answers.launchpad.net/madgraph5
MadGraph5Error : A compilation Error occurs when trying to compile /afs/in2p3.fr/home/r/ruizalva/public/MadGraph5_v1_5_7/SA_v4/SubProcesses/P0_qq_h0a0.
 The compilation fails with the following output message:
     gfortran -O -w -ffixed-line-length-132 -w -c -o symmetry.o symmetry.f
     touch qmass.inc
     gfortran -O -w -ffixed-line-length-132 -w -c -o cuts.o cuts.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o cluster.o cluster.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o myamp.o myamp.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o genps.o genps.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o initcluster.o initcluster.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o setscales.o setscales.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o reweight.o reweight.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o get_color.o get_color.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o idenparts.o idenparts.f
     gfortran -O -w -ffixed-line-length-132 -w -c -o matrix1.o matrix1.f
      In file coupl.inc:10

          Included at matrix1.f:237

           double precision DUM0
                               1
     Error: Symbol 'dum0' at (1) already has basic type of COMPLEX
      In file coupl.inc:13

          Included at matrix1.f:237

           double precision DUM1
                               1
     Error: Symbol 'dum1' at (1) already has basic type of COMPLEX
     make: *** [matrix1.o] Error 1
     make: *** Waiting for unfinished jobs....

 Please try to fix this compilations issue and retry.
 Help might be found at https://answers.launchpad.net/madgraph5.
 If you think that this is a bug, you can report this at https://bugs.launchpad.net/madgraph5

I'm working on v1.5.7 where this bug is supossed to be fixed. Do you know what I'm doing wrong?

Thanks,
Jose

Hello Jose,

This seems to be an issue with the v4 model output between different versions of FeynRules. Some versions don't define the DUM variables (which is why we define them directory in the MG5 code in v. 1.5.7. It seems that in the FR output you have, these variables are defined directly in the FR model files. The easiest solution is to simply remove them from the model files; simply do
grep -n -i DUM models/your_model_name/*
and you'll find all occurrences.

All the best,
Johan

Thanks Johan Alwall, that solved my question.

Hi Johan,

Now it's running nicely! But, I go back to my previous question. Now I have running v4 and UFO models in MG5, and I see a big discrepancy between the cross sections calculated using each of them. I assume then is a bug on FR. Or is something related to MG5?

Thanks,
Jose

Hello Jose,

As Olivier said, since the MGv4 output in FR is not really supported anymore, I wouldn't worry too much. However, if you want to really dig deeper into where the difference comes from, you should in principle be able to compare the matrix element calculation (in matrix.f) line by line in the two implementations, since the resulting diagrams should be identical. I would suggest to do this using the standalone output, where you can easily run a matrix element calculation for a given phase space point. That way you can see in exactly which wavefunction calls you get a difference, and deduce which interaction has problems. First thing to check of course is that all the parameters and coupling constants are identical (they are printed at the top of the run log in standalone mode).

Hope this helps, all the best,
Johan

Hello Johan,

Thanks a lot. I'll do the checks.

Cheers,
Jose