how to do 5 jets or more in the final states

a follow-up.
A closer look at the matrix1.f reveals a line that starts like this:

      JAMP(1)=+1./2.*(-AMP(3)-AMP(8)-IMAG1*AMP(43)+AMP(44)-1./3.*IMAG1
     $ *AMP(45)-AMP(57)-IMAG1*AMP(58)-AMP(59)-1./3.*AMP(61)-1./3.
     $ *AMP(62)+IMAG1*AMP(92)-IMAG1*AMP(94)+IMAG1*AMP(95)-IMAG1
     $ *AMP(97)-1./3.*IMAG1*AMP(98)-IMAG1*AMP(101)-1./3.*IMAG1
     $ *AMP(102)+AMP(106)-IMAG1*AMP(117)-IMAG1*AMP(118)+AMP(119)
     $ -AMP(125)-IMAG1*AMP(127)-AMP(128)+AMP(148)-IMAG1*AMP(149)
     $ +IMAG1*AMP(150)-IMAG1*AMP(152)+IMAG1*AMP(153)-1./3.*IMAG1
     $ *AMP(175)-1./3.*IMAG1*AMP(176)-1./3.*AMP(182)-1./3.*AMP(183)

and continues for many thousands of lines. Could it be that the compiler (which, to make things worse,
is called with -O option) chokes trying to process such a long string of additions?

Hi Yuri,

The official limit for the number of jet is currently 4j in final
states.
The problem is that after 4j the description in term of Feynman
diagram is
very heavy.
As you point MG5 is able to produce a valid output, but this one is
much too heavy to be compile in fortran.
(one of the problem is JAMP, another one is the color matrix)

By refactoring the output file, one user/collaborator succeeds to
computes
g g > 7 g
https://indico.cern.ch/contributionDisplay.py?sessionId=22&contribId=114&confId=121170

On our side, we have different idea/ work in progress to solve such
problem, but you will need to be patient.

Cheers,

Olivier

On Feb 21, 2012, at 9:35 AM, Yuri Gershtein wrote:

> Question #188406 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/188406
>
> Yuri Gershtein gave more information on the question:
> a follow-up.
> A closer look at the matrix1.f reveals a line that starts like this:
>
> JAMP(1)=+1./2.*(-AMP(3)-AMP(8)-IMAG1*AMP(43)+AMP(44)-1./3.*IMAG1
> $ *AMP(45)-AMP(57)-IMAG1*AMP(58)-AMP(59)-1./3.*AMP(61)-1./3.
> $ *AMP(62)+IMAG1*AMP(92)-IMAG1*AMP(94)+IMAG1*AMP(95)-IMAG1
> $ *AMP(97)-1./3.*IMAG1*AMP(98)-IMAG1*AMP(101)-1./3.*IMAG1
> $ *AMP(102)+AMP(106)-IMAG1*AMP(117)-IMAG1*AMP(118)+AMP(119)
> $ -AMP(125)-IMAG1*AMP(127)-AMP(128)+AMP(148)-IMAG1*AMP(149)
> $ +IMAG1*AMP(150)-IMAG1*AMP(152)+IMAG1*AMP(153)-1./3.*IMAG1
> $ *AMP(175)-1./3.*IMAG1*AMP(176)-1./3.*AMP(182)-1./3.*AMP(183)
>
>
> and continues for many thousands of lines. Could it be that the
> compiler (which, to make things worse,
> is called with -O option) chokes trying to process such a long
> string of additions?
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Hi Olivier,

how patient would you like me to be?
Is this something in the works close to resolution or is it a long-term project?

Do you understand why the compiler chokes on the output?
Where is the limitation - is it the file size, length of lines, etc?

thanks,
Yuri

Hi Yuri,

>how patient would you like me to be?
>Is this something in the works close to resolution or is it a long-term project?

Personally I don't know how things are moving in that direction. Johan? Fabio?

>Do you understand why the compiler chokes on the output?
>Where is the limitation - is it the file size, length of lines, etc?

I think this both file size and length size, and probably also memory size (for the size of the color matrix)
But Yoshitaro should have more insight about this.

Cheers,

Olivier

by the way, we've figured out that once can compile matrix1.f (that was the original error) by hand if -O option is dropped.
I'll try to do that and see how far I'd get.

Hello Yuri,

For multijet final states (> 4) work is, as Olivier mentioned, ongoing but it's difficult to give you a definite time-line. If you have a paper in the works, I would suggest not to wait for us but run up to 4 jets with ickkw set to 1 and let Pythia take care of the 5th jet for now, it's usually not doing a bad job for high jet multiplicities (depending on the particular jet configurations you need).

All the best,
Johan

Hi Yuri,

Some time ago I was able to calculate full p p > j j j j j (five jets) process by changing gfortran flags in makefile. As was mentioned before the problem with this process is mainly the size of color matrix. By adding flag -fno-automatic you force compiler to flush parts that are ready out from memory (reducing optimization level is than not necessary, you can actually increase it to get faster code). I got something like 2k jobs so this must be run on a cluster. Mind you, that although I got a result I didn't check it's validity. It's highly probable that this trick can brake something so you need to validate somehow your result.

Best regard,
Wojtek

Hi,

thanks everyone for comments.

Even without -O flag, 10 out of 127 matrix*.f files gave seg fault.

I definitively narrowed it down to the part of the code where
JAMP()'s are filled. The length of the lines is HUGE. I wrote a simple code that splits that line into several,
and things compile. Even the ones that compiled before compile much, much faster.

I think that one simple change that authors can make in the next version is to ask PYTHON to split it when the
file is generated.

Another important but minor change needs to be made to the symfact.dat.
Currently the format is too short, so the two integers merge if the second is negative, i.e.
 54054-17847

I just replaced '-' with ' -' and that worked.

regards,
Yuri

Thanks for those comments,

> I think that one simple change that authors can make in the next
> version is to ask PYTHON to split it when the
> file is generated.

Johan, would it be possible to do that in the FortranWriter class?
(If a line is too big and start by "XXXX =" split it automatically in
a smart way?)

> Another important but minor change needs to be made to the
> symfact.dat.
> Currently the format is too short, so the two integers merge if the
> second is negative, i.e.
> 54054-17847
>
> I just replaced '-' with ' -' and that worked.

That I don't understand, the line formating as a mandatory space...

Note that for such process, you probably also need to change the size
definition of various vector.
like
       integer max_amps
       parameter (max_amps=9999)

On 23-févr.-12, at 23:20, Yuri Gershtein wrote:

> Question #188406 on MadGraph5 changed:
> https://answers.launchpad.net/madgraph5/+question/188406
>
> Yuri Gershtein posted a new comment:
> Hi,
>
> thanks everyone for comments.
>
> Even without -O flag, 10 out of 127 matrix*.f files gave seg fault.
>
> I definitively narrowed it down to the part of the code where
> JAMP()'s are filled. The length of the lines is HUGE. I wrote a
> simple code that splits that line into several,
> and things compile. Even the ones that compiled before compile much,
> much faster.
>
> I think that one simple change that authors can make in the next
> version is to ask PYTHON to split it when the
> file is generated.
>
> Another important but minor change needs to be made to the
> symfact.dat.
> Currently the format is too short, so the two integers merge if the
> second is negative, i.e.
> 54054-17847
>
> I just replaced '-' with ' -' and that worked.
>
> regards,
> Yuri
>
> --
> You received this question notification because you are a member of
> MadTeam, which is an answer contact for MadGraph5.

Hello Yuri, Olivier

> I think that one simple change that authors can make in the next
> version is to ask PYTHON to split it when the
> file is generated.

> Johan, would it be possible to do that in the FortranWriter class?
> (If a line is too big and start by "XXXX =" split it automatically in
> a smart way?)

This can be done, either in the FortranWriter or in the generating code. However, the code is really not meant to generate so big processes, so I would definitely suggest to use 4j+Pythia for now and wait for the multiparton code, which should be out sometime this spring.

> Another important but minor change needs to be made to the
> symfact.dat.
> Currently the format is too short, so the two integers merge if the
> second is negative, i.e.
> 54054-17847
>
> I just replaced '-' with ' -' and that worked.

I think the formatting is indeed with a fixed number of spaces. This we should certainly fix. Thanks!

> Note that for such process, you probably also need to change the size
> definition of various vector.
> like
> integer max_amps
> parameter (max_amps=9999)

I'm pretty sure there should be no such places left (they should all be generated by the python code). Let me know if you find any, and I'll make sure to fix them.

Cheers,
Johan

Hi,

Just to say that
symfact.dat should be correctly formatted in 1.4.3 even with such large number of diagram
and that all fixed memory stuff that I pointed in my precedent post are also now passed as dynamical value.

On the other hand, the automatic splitting of the line is NOT implemented. (maybe for a future version)

Cheers,

Olivier