Slow compilation on Ubuntu 20.04

Hi,

One option is to fully remove the call to madevent_forhel. by setting the parameter "hel_recycling" to False in the run_card.dat.
But this will likely not change the issue since you can not bypass the next call the madevent binary which will likely be slow too...
But maybe worth the shot...

The second thing to check is the version of GCC on each system. We do expect some speed difference due to GCC version and it would make sense to install the same version on all system to check if this is the problem or not...

After that, one need to check the usage/speed of the RAM and the performance of the IO if the issue is not related.

Cheers,

Olivier

When generating 250000 events:
- EPYC 7H12 (Ubuntu 22.04)
 - with hel_recycling=True (default) is still compiling process 3/24 after more than 20 minutes
 - with hel_recycling=False takes 11m56.289s
- i7-6700K (Arch Linux)
 - with hel_recycling=True (default) takes 7m2s
 - with hel_recycling=False takes 10m3s

While setting "hel_recycling" to false does result in a significant performance improvement for the EPYC 7H12, it still falls bellow the i7-6700K with or without "hel_recycling".

In order to check the impact of the GCC version, I ran madevent_hel on both Ubuntu virtual machines with gcc/g++/gfortran 10.5.0.
As you'll see in https://pasteboard.co/upWWmKPuDspo.png, Ubuntu 22.04 retains a significantly improved performance over 20.04, even under these circumstances.

I do not expect usage/speed of the RAM and the performance of the IO to be a significant factor since the two Ubuntu virtual machines exhibit very different performances despite running on the same system.
Nonetheless, do you have a suggestion on how to quantify these factors on the two systems?

You right, does not make that much sense...

Which process/model are you testing?
I would like to see if I can reproduce this on some openstack machine, and then profile the code on that machine to see if I do spot an anomaly in the performance...

Cheers,

Olivier

Hi, I'm studying the pSPSS model in https://feynrules.irmp.ucl.ac.be/wiki/pSPSS.
I provide a working example below, but I can also try to find something more minimal if you prefer.

import model pSPSS

define ww = W+ W-
define mu = mu+ mu-
define vmu = vm vm~
define j = g u u~ c c~ d d~ s s~ b b~
define nn = n4 n5

generate e- e+ > Z > vmu nn, (nn > mu j j)

output example

launch example
    shower=OFF
    detector=OFF
    analysis=OFF

    done

    set sde_strategy 1

    set time_of_flight 0.
    set ptl -1

    set maxjetflavor=5

    set nevents 250000
    set ebeam1 45.0
    set ebeam2 45.0

    set Mmaj 14.0
    set deltaM 7.43e-13
    set theta1 0
    set theta2 0.0003
    set theta3 0

    set WN4 Auto
    set WN5 Auto

    done

If you're experiencing slow compilation times on Ubuntu 20.04, there could be several reasons behind this issue. Here are some common factors and solutions to consider:

Insufficient System Resources:

Solution: Check your system resources using tools like htop or the System Monitor. If your CPU or memory usage is consistently high during compilation, consider upgrading your hardware or optimizing your code.
Outdated Software:

Solution: Ensure that your development tools and dependencies are up-to-date. Use the package manager (apt in the case of Ubuntu) to update your system:
bash
Copy code
sudo apt update
sudo apt upgrade
https://pickerwheel.net/

So I did test your process (but only on my mac so far).

The first striking point is that you do have that warning:

WARNING: The optimizer detects that you have coupling evaluated to zero:
GC_16 GC_19 GC_79 GC_82
This will slow down the computation. Please consider using restricted model:
https://answers.launchpad.net/mg5amcnlo/+faq/2312

Since you are reporting efficiency issue it might be good to apply the method.
Indeed when running in debug mode, I do see they they are two classes of SubProcesses behavior.
Some returning expected information like process 1 and 2:

DEBUG: nb_hel: 10 zero amp: 0 bad_amps_hel: 0/10
DEBUG: nb_hel: 10 zero amp: 0 bad_amps_hel: 0/10
INFO: Compiling for process 2/24.
INFO: P1_emep_vln4_n4_mumusx
DEBUG: nb_hel: 11 zero amp: 0 bad_amps_hel: 0/11
DEBUG: nb_hel: 13 zero amp: 0 bad_amps_hel: 0/13

and some like process 3 that fails to determine the contributing helicity and therefore runs a longer time (up to a maximum of try).

INFO: Compiling for process 3/24.
INFO: P1_emep_vln4_n4_mumubx
DEBUG: nb_hel: 0 zero amp: 1 bad_amps_hel: 0/0
DEBUG: "No helicity", self.input_file = No helicity /Users/omattelaer/Documents/git_workspace/LTS/example/SubProcesses/P1_emep_vln4_n4_mumubx/matrix1_orig.f [hel_recycle.py at line 737]
DEBUG: nb_hel: 0 zero amp: 1 bad_amps_hel: 0/0
DEBUG: "No helicity", self.input_file = No helicity /Users/omattelaer/Documents/git_workspace/LTS/example/SubProcesses/P1_emep_vln4_n4_mumubx/matrix2_orig.f [hel_recycle.py at line 737]

moving the file example/Cards/param_card.dat within your UFO model directory and give him the name restrict_benchmark1.dat
and then change the line
import model pSPSS
to
import model pSPSS-benchmark1

will remove those processes from the start if that's the issue.
In any case it would be interesting to see if the slow down that you observe is only on the zero cross-section processes or for the contributing one.

Cheers,

Olivier

Response to Picker Wheel (pickerwheel1233):

 Insufficient System Resources: I do not expect this to be an issue since the two virtual machines running on the same physical hardware yielded significantly different results.

Outdated Software: I confirm the software on both Ubuntu virtual machines is up to date.

Response to Olivier Mattelaer (olivier-mattelaer):

Following your suggestion, I added the file "restrict_mubenchark.dat" to the "pSPSS" model folder with the following contents:
######################################################################
## 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 MASS
###################################
Block mass
    1 5.040000e-03 # md
    2 2.550000e-03 # mup
    3 1.010000e-01 # ms
    4 1.270000e+00 # mc
    5 4.700000e+00 # mb
    6 1.720000e+02 # mt
   11 5.110000e-04 # me
   13 1.056600e-01 # mmu
   15 1.777000e+00 # mta
   23 9.118760e+01 # mZ
   25 1.250000e+02 # MH
## 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.
  12 0.000000e+00 # ve : 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)))
  8000011 2.000000e+01 # n4 : -0.5*deltaM + Mmaj*(1 + thetasqr/2.)
  8000012 2.000000e+01 # n5 : deltaM/2. + Mmaj*(1 + thetasqr/2.)

###################################
## INFORMATION FOR PSPSS
###################################
Block pspss
    1 2.000000e+01 # Mmaj
    2 1.000000e-12 # deltaM
    3 0.000000e+00 # theta1
    4 1.000000e-04 # theta2
    5 0.000000e+00 # theta3
    6 0.000000e+00 # damping

###################################
## 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
    1 5.040000e-03 # ymdo
    2 2.550000e-03 # ymup
    3 1.010000e-01 # yms
    4 1.270000e+00 # ymc
    5 4.700000e+00 # ymb
    6 1.720000e+02 # ymt
   11 5.110000e-04 # yme
   13 1.056600e-01 # ymm
   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 8000011 1.000000e-05 # Wn4
DECAY 8000012 1.000000e-05 # Wn5
## 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
#===========================================================
# QUANTUM NUMBERS OF NEW STATE(S) (NON SM PDG CODE)
#===========================================================

Block QNUMBERS 8000011 # n4
        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 0 # Particle/Antiparticle distinction (0=own anti)
Block QNUMBERS 8000012 # n5
        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 0 # Particle/Antiparticle distinction (0=own anti)

Likewise, I changed the model import in madgraph to "import model pSPSS-mubenchmark", leading to:
import model pSPSS-mubenchmark

define ww = W+ W-
define mu = mu+ mu-
define vmu = vm vm~
define j = g u u~ c c~ d d~ s s~ b b~
define nn = n4 n5

generate e- e+ > Z > vmu nn, (nn > mu j j)

output example

launch example
    shower=OFF
    detector=OFF
    analysis=OFF

    done

    set sde_strategy 1

    set time_of_flight 0.
    set ptl -1

    set maxjetflavor=5

    set nevents 250000
    set ebeam1 45.0
    set ebeam2 45.0

    set Mmaj 14.0
    set deltaM 7.43e-13
    set theta1 0
    set theta2 0.0003
    set theta3 0

    set WN4 Auto
    set WN5 Auto

    done

While this reduces the total number of processes from 24 to 16, the remaining processes retain the significantly larger compilation time on Ubuntu 20.04 when compared to Ubuntu 22.04.

Hi Olivier,

thanks for your input. Definitely the advice concerning the restriction card sped thinks up. However, I do not think that it tackled our issue. Since the difference shows up when changing the operating system, even when keeping the GCC and MG version constant, I suspect another dependency to influence our calculation. Unfortunately we can not change the OS version on the server at the moment, hence we are quite desperate to find this dependency. Do you have more ideas for things we could check.

Best,
Jan

Hi Jan,

The short answer is that i have no clue on what can be reasonable explanation for this.

Maybe one suggestion would be to not test with virtual machine but test with singularity image (or docker obviously)
The main reason for such test is that in that case, you will use the same kernel than the host and therefore will be able to test if this is kernel related.

Related question are you using the same kernel for all machine/OS? Do they differ by the major number or only by some small digit.
And how much up-to-date are they? As you know the last years have been prolific in kernel security bug and therefore kernel patch reducing the efficiency of the computation to avoid those security issue. A factor of 10 seems large for such effect so this is a wild guess at this stage.

Cheers,

Olivier

Hi Olivier,

Starting by your latter question, `uname -a` outputs the following on each system:
Arch Linux (i7-6700K - bare metal): Linux GroundControl 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000 x86_64 GNU/Linux
Fedora Linux 37 (Ryzen 9 3950X - bare metal): Linux node1.tecnico.ulisboa.pt 6.5.5-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Sep 23 22:53:27 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Fedora Linux 38 (Ryzen Threadripper 3970X - bare metal): Linux node2.ist.utl.pt 6.5.5-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Sep 24 15:52:44 UTC 2023 x86_64 GNU/Linux
Ubuntu 22.04 (i7-6700K - virtual machine): Linux ubuntu2204 5.15.0-92-generic #102-Ubuntu SMP Wed Jan 10 09:33:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 20.04 (i7-6700K - virtual machine): Linux ubuntu2004 5.4.0-170-generic #188-Ubuntu SMP Wed Jan 10 09:51:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 20.04 (EPYC 7H12 - bare metal): Linux demon 5.4.0-139-generic #156-Ubuntu SMP Fri Jan 20 17:27:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

If I understood your hypothesis correctly, we expect the newer kernels to be the ones with the performance issues, which does not seem to be in agreement with what we've observed thus far.

I am open to testing further with Singularity and/or Docker, though I would ask for some guidance on this.
In particular, while I have some experience with Docker, I have never used Singularity.
Furthermore, while a simple search lead me to https://github.com/scailfin/MadGraph5_aMC-NLO and https://hub.docker.com/r/hfukuda/madgraph among others, I would greatly appreciate your insight into if there's a recommended implementation.

Best,
Bruno

Hi,

> If I understood your hypothesis correctly, we expect the newer kernels
> to be the ones with the performance issues, which does not seem to be in
> agreement with what we've observed thus far.

As I said, I'm fully on the dark. The only clear statement is that the issue is not on the MG5aMC level.
If this is not not the compilator, it can only be something like glibc (which I'm not sure what it is) or the kernel (also not sure what it does). Maybe the best is to ask your local HPC center for a true informatician to look at this.

For the kernel behaviour I would have expected to have a (series) of drop in the performance and then a partial recovery of the performance with time.

> I am open to testing further with Singularity and/or Docker, though I would ask for some guidance on this.
> In particular, while I have some experience with Docker, I have never used Singularity.
> Furthermore, while a simple search lead me to https://github.com/scailfin/MadGraph5_aMC-NLO and https://hub.docker.com/r/hfukuda/madgraph among others, I would greatly appreciate your insight into if there's a recommended implementation.

I'm actually discovering both, the first link some more serious and I had interaction with them due to multiple issue that they had when setup-ing it. So personally, I would try that one first.

Cheers,

Olivier

> On 7 Feb 2024, at 23:10, Bruno Miguel Silva de Oliveira <email address hidden> wrote:
>
> Question #709178 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/709178
>
> Status: Answered => Open
>
> Bruno Miguel Silva de Oliveira is still having a problem:
> Hi Olivier,
>
> Starting by your latter question, `uname -a` outputs the following on each system:
> Arch Linux (i7-6700K - bare metal): Linux GroundControl 6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000 x86_64 GNU/Linux
> Fedora Linux 37 (Ryzen 9 3950X - bare metal): Linux node1.tecnico.ulisboa.pt 6.5.5-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Sep 23 22:53:27 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> Fedora Linux 38 (Ryzen Threadripper 3970X - bare metal): Linux node2.ist.utl.pt 6.5.5-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Sep 24 15:52:44 UTC 2023 x86_64 GNU/Linux
> Ubuntu 22.04 (i7-6700K - virtual machine): Linux ubuntu2204 5.15.0-92-generic #102-Ubuntu SMP Wed Jan 10 09:33:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
> Ubuntu 20.04 (i7-6700K - virtual machine): Linux ubuntu2004 5.4.0-170-generic #188-Ubuntu SMP Wed Jan 10 09:51:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
> Ubuntu 20.04 (EPYC 7H12 - bare metal): Linux demon 5.4.0-139-generic #156-Ubuntu SMP Fri Jan 20 17:27:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
>
> If I understood your hypothesis correctly, we expect the newer kernels
> to be the ones with the performance issues, which does not seem to be in
> agreement with what we've observed thus far.
>
> I am open to testing further with Singularity and/or Docker, though I would ask for some guidance on this.
> In particular, while I have some experience with Docker, I have never used Singularity.
> Furthermore, while a simple search lead me to https://github.com/scailfin/MadGraph5_aMC-NLO and https://hub.docker.com/r/hfukuda/madgraph among others, I would greatly appreciate your insight into if there's a recommended implementation.
>
> Best,
> Bruno
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,

The Docker image in https://github.com/scailfin/MadGraph5_aMC-NLO is based on Debian 11 which, according to https://askubuntu.com/questions/445487/what-debian-version-are-the-different-ubuntu-versions-based-on, is closest to Ubuntu 21.10 - the third and final release between 20.04 (with issue) and 22.04 (without issue).
It therefore seemed logical to me to test it on the two virtual machines, by installing Docker and running the following commands:
- sudo docker pull scailfin/madgraph5-amc-nlo:mg5_amc3.5.1
- sudo docker run --rm -ti -v $PWD:$PWD -w $PWD scailfin/madgraph5-amc-nlo:mg5_amc3.5.1
- cp -r .local/install/MG5_aMC_v3_5_3/models/pSPSS /usr/local/venv/MG5_aMC/models/
- mg5_aMC example.history

While the Ubuntu 20.04 virtual machine retains it's slow performance on Docker, the Ubuntu 22.04 becomes slow when Docker is used.
As such, I would say that, rather than being an issue with the kernel, this is more likely a problem in some library in Ubuntu 20.04 and 21.10, but not 22.04.
If this is the case, we would expect an image based on Ubuntu 22.04 to have good performance everywhere, but I'm not sure how easy something like that would be to implement.

Best,
Bruno

Thanks this is super interesting.

The github above seems to create image with "ubuntu-latest"

So if you create your own fork of the repo and run the workflow script (did not check what was the trigger of such script manual/ PR/ ...) You should be able to have one for ubuntu-22
Note that due to controlling the amount of github action that you run, you will need to allow them manually (as far as i know).

Olivier

> On 8 Feb 2024, at 10:25, Bruno Miguel Silva de Oliveira <email address hidden> wrote:
>
> Question #709178 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/709178
>
> Status: Answered => Open
>
> Bruno Miguel Silva de Oliveira is still having a problem:
> Hi,
>
> The Docker image in https://github.com/scailfin/MadGraph5_aMC-NLO is based on Debian 11 which, according to https://askubuntu.com/questions/445487/what-debian-version-are-the-different-ubuntu-versions-based-on, is closest to Ubuntu 21.10 - the third and final release between 20.04 (with issue) and 22.04 (without issue).
> It therefore seemed logical to me to test it on the two virtual machines, by installing Docker and running the following commands:
> - sudo docker pull scailfin/madgraph5-amc-nlo:mg5_amc3.5.1
> - sudo docker run --rm -ti -v $PWD:$PWD -w $PWD scailfin/madgraph5-amc-nlo:mg5_amc3.5.1
> - cp -r .local/install/MG5_aMC_v3_5_3/models/pSPSS /usr/local/venv/MG5_aMC/models/
> - mg5_aMC example.history
>
> While the Ubuntu 20.04 virtual machine retains it's slow performance on Docker, the Ubuntu 22.04 becomes slow when Docker is used.
> As such, I would say that, rather than being an issue with the kernel, this is more likely a problem in some library in Ubuntu 20.04 and 21.10, but not 22.04.
> If this is the case, we would expect an image based on Ubuntu 22.04 to have good performance everywhere, but I'm not sure how easy something like that would be to implement.
>
> Best,
> Bruno
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,

Since I don't have much experience with GitHub actions, I instead wrote a minimal Dockerfile as follows:
(BEGIN Dockerfile)
# syntax=docker/dockerfile:1

# ----- Base image -----
# Either ubuntu:focal (20.04) or ubuntu:jammy (22.04)
FROM ubuntu:focal

# ----- User and workdir -----
USER root
WORKDIR /

# ----- Dependencies -----
RUN apt update -y
RUN apt upgrade -y

RUN apt install -y --no-install-recommends gcc g++ gfortran make cmake bash-completion wget ca-certificates python3 python3-six python3-numpy unzip

RUN apt clean -y
RUN apt autoremove -y
RUN rm -rf /var/lib/apt/lists/*

# ----- MadGraph5_aMC@NLO -----
ARG MG_MAJOR_VERSION="3"
ARG MG_MINOR_VERSION="3.5"
ARG MG_PATCH_VERSION="3.5.3"

ENV MG_TAR_GZ="/usr/local/MG5_aMC.tar.gz"
ENV MG_DIR="/usr/local/MG5_aMC"
ENV MG_BIN_DIR="${MG_DIR}/bin"

RUN wget https://launchpad.net/mg5amcnlo/${MG_MAJOR_VERSION}.0/${MG_MINOR_VERSION}.x/+download/MG5_aMC_v${MG_PATCH_VERSION}.tar.gz -O ${MG_TAR_GZ}
RUN mkdir -p ${MG_DIR}
RUN tar -xzvf ${MG_TAR_GZ} --strip=1 --directory=${MG_DIR}
RUN rm ${MG_TAR_GZ}
RUN ls /usr/local/
RUN printf '\nexport PATH="${MG_BIN_DIR}:$PATH"\n' >> /root/.bashrc

# ----- Shell -----
SHELL [ "/bin/bash", "-c" ]
(END Dockerfile)

I am then able to create the appropriate docker images on my local machine using:
- sudo docker build . -t mg5_amc:ubuntu2004
and run them with:
- sudo docker run --rm -ti -v $PWD:$PWD -w $PWD mg5_amc:ubuntu2004
which allows me to run MadGraph5_aMC@NLO scripts such as:
(BEGIN example.history)
import model pSPSS

define ww = W+ W-
define mu = mu+ mu-
define vmu = vm vm~
define j = g u u~ c c~ d d~ s s~ b b~
define nn = n4 n5

generate e- e+ > Z > vmu nn, (nn > mu j j)

output example

launch example
    shower=OFF
    detector=OFF
    analysis=OFF

    done

    set sde_strategy 1

    set time_of_flight 0.
    set ptl -1

    set maxjetflavor=5

    set nevents 250000
    set ebeam1 45.0
    set ebeam2 45.0

    set Mmaj 14.0
    set deltaM 7.43e-13
    set theta1 0
    set theta2 0.0003
    set theta3 0

    set WN4 Auto
    set WN5 Auto

    done
(END example.history)

Following this procedure, I got similar results for the Ubuntu 20.04 and 22.04 virtual machines, namely:
- The Docker image based on Ubuntu 20.04 had the slow compilation issue, regardless of whether the host OS was Ubuntu 20.04 or 22.04
- The Docker image based on Ubuntu 22.04 did not have the slow compilation issue, regardless of whether the host OS was Ubuntu 20.04 or 22.04

I believe this further reinforces our hypothesis that the issue lies somewhere in Ubuntu 20.04's programs and/or libraries.
Nonetheless, I may be misinterpreting what Docker is doing and therefore would like your opinion on this matter.

Best,
Bruno

Hi,

Yeah this clearly kill my idea that this can be kernel related and therefore this should be related to some OS library
(maybe glibc ?)

Cheers,

Olivier

> On 9 Feb 2024, at 16:20, Bruno Miguel Silva de Oliveira <email address hidden> wrote:
>
> Question #709178 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/709178
>
> Status: Answered => Open
>
> Bruno Miguel Silva de Oliveira is still having a problem:
> Hi,
>
> Since I don't have much experience with GitHub actions, I instead wrote a minimal Dockerfile as follows:
> (BEGIN Dockerfile)
> # syntax=docker/dockerfile:1
>
> # ----- Base image -----
> # Either ubuntu:focal (20.04) or ubuntu:jammy (22.04)
> FROM ubuntu:focal
>
> # ----- User and workdir -----
> USER root
> WORKDIR /
>
> # ----- Dependencies -----
> RUN apt update -y
> RUN apt upgrade -y
>
> RUN apt install -y --no-install-recommends gcc g++ gfortran make cmake
> bash-completion wget ca-certificates python3 python3-six python3-numpy
> unzip
>
> RUN apt clean -y
> RUN apt autoremove -y
> RUN rm -rf /var/lib/apt/lists/*
>
> # ----- MadGraph5_aMC@NLO -----
> ARG MG_MAJOR_VERSION="3"
> ARG MG_MINOR_VERSION="3.5"
> ARG MG_PATCH_VERSION="3.5.3"
>
> ENV MG_TAR_GZ="/usr/local/MG5_aMC.tar.gz"
> ENV MG_DIR="/usr/local/MG5_aMC"
> ENV MG_BIN_DIR="${MG_DIR}/bin"
>
> RUN wget https://launchpad.net/mg5amcnlo/${MG_MAJOR_VERSION}.0/${MG_MINOR_VERSION}.x/+download/MG5_aMC_v${MG_PATCH_VERSION}.tar.gz -O ${MG_TAR_GZ}
> RUN mkdir -p ${MG_DIR}
> RUN tar -xzvf ${MG_TAR_GZ} --strip=1 --directory=${MG_DIR}
> RUN rm ${MG_TAR_GZ}
> RUN ls /usr/local/
> RUN printf '\nexport PATH="${MG_BIN_DIR}:$PATH"\n' >> /root/.bashrc
>
> # ----- Shell -----
> SHELL [ "/bin/bash", "-c" ]
> (END Dockerfile)
>
> I am then able to create the appropriate docker images on my local machine using:
> - sudo docker build . -t mg5_amc:ubuntu2004
> and run them with:
> - sudo docker run --rm -ti -v $PWD:$PWD -w $PWD mg5_amc:ubuntu2004
> which allows me to run MadGraph5_aMC@NLO scripts such as:
> (BEGIN example.history)
> import model pSPSS
>
> define ww = W+ W-
> define mu = mu+ mu-
> define vmu = vm vm~
> define j = g u u~ c c~ d d~ s s~ b b~
> define nn = n4 n5
>
> generate e- e+ > Z > vmu nn, (nn > mu j j)
>
> output example
>
> launch example
> shower=OFF
> detector=OFF
> analysis=OFF
>
> done
>
> set sde_strategy 1
>
> set time_of_flight 0.
> set ptl -1
>
> set maxjetflavor=5
>
> set nevents 250000
> set ebeam1 45.0
> set ebeam2 45.0
>
> set Mmaj 14.0
> set deltaM 7.43e-13
> set theta1 0
> set theta2 0.0003
> set theta3 0
>
> set WN4 Auto
> set WN5 Auto
>
> done
> (END example.history)
>
> Following this procedure, I got similar results for the Ubuntu 20.04 and 22.04 virtual machines, namely:
> - The Docker image based on Ubuntu 20.04 had the slow compilation issue, regardless of whether the host OS was Ubuntu 20.04 or 22.04
> - The Docker image based on Ubuntu 22.04 did not have the slow compilation issue, regardless of whether the host OS was Ubuntu 20.04 or 22.04
>
> I believe this further reinforces our hypothesis that the issue lies somewhere in Ubuntu 20.04's programs and/or libraries.
> Nonetheless, I may be misinterpreting what Docker is doing and therefore would like your opinion on this matter.
>
> Best,
> Bruno
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi,

For now we'll try to sidestep the issue with docker.
Nonetheless, I am available if there's anything you need help with.

Best,
Bruno

If you're experiencing slow compilation on Ubuntu 20.04, there could be several factors contributing to this issue. Let's explore some potential causes and solutions:

1. System Resources:
Insufficient RAM: Insufficient RAM can significantly slow down compilation processes, especially for large projects. Consider upgrading your RAM if possible.
CPU Usage: Monitor CPU usage during compilation. If it's consistently high, it could indicate that your CPU is struggling to handle the workload.
visit: https://tocalifeworldsapk.com/