Undefined symbols for architecture arm64

Asked by Shi-Ping He

Dear MadGraph developers,

I am testing the g g > g g h h process provided in V. Hirschia and O. Mattelaer's paper (arXiv:1507.00020).

I run the following commands:
generate g g > g g h h [sqrvirt=QCD]
output standalone 1
launch 1

Then, I obtained the following results:

|================================================================================================
|| Results for process gg > gghh (Loop-induced)
|================================================================================================
|| Phase-Space point specification (E,px,py,pz)
|
| 5.0000000000000000e+02 0.0000000000000000e+00 0.0000000000000000e+00 5.0000000000000000e+02
| 5.0000000000000000e+02 0.0000000000000000e+00 0.0000000000000000e+00 -5.0000000000000000e+02
| 8.2699870436642712e+01 -2.0640279037102381e+01 3.7431847739289353e+01 -7.0796216186535759e+01
| 3.0663344631872172e+02 -9.6987240636697933e+01 -2.8198200512458772e+02 7.1440145162875041e+01
| 1.8939780888763451e+02 -9.8884357175572646e+01 -9.1252995876172164e+01 4.6274233230103313e+01
| 4.2126887435700098e+02 2.1651187684937301e+02 3.3580315326147058e+02 -4.6918162206442616e+01
|
| Stable kinematic configuration (SPS).
| Estimated relative accuracy = 5.4e-12
|
|| Loop amplitude squared, must be finite:
| Finite = 4.5743546590095728e-11
|(| Pole residues, indicated only for checking purposes: )
|( Single pole = 3.7448854569450888e-25 )
|( Double pole = 2.5817274055760012e-35 )
|
|
|| All virtual contributions are of split orders *(QCD=8)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Because the above kinematic configuration is different from that in V. Hirschia and O. Mattelaer's paper (arXiv:1507.00020), I tried to change the phase space point. In the file "check_sa.f", I changed the kinematic configuration and uncommented the corresponding part. The details are as follows:

      buff(1)=" 0.5000000E+03 0.0000000E+00 0.0000000E+00 0.5000000E+03"
      buff(2)=" 0.5000000E+03 0.0000000E+00 0.0000000E+00 -0.5000000E+03"
      buff(3)=" 0.1485566E+03 -0.2003506E+02 0.3633427E+02 -0.6872033E+02"
      buff(4)=" 0.3228250E+03 -0.9414338E+02 -0.2737137E+03 0.6934538E+02"
      buff(5)=" 0.1381181E+03 -0.9598487E+02 -0.8857728E+02 0.4491738E+02"
      buff(6)=" 0.3905004E+03 0.2101633E+03 0.3259567E+03 -0.4554243E+02"
C C
C C Here the k,E,px,py,pz are read from the string into the
C momenta array.
C C k=1,2 : incoming
C C k=3,nexternal : outgoing
C C
      do i=1,nexternal
      read (buff(i),*) k, P(0,i),P(1,i),P(2,i),P(3,i)
      enddo
C
C C print the momenta out
C
      do i=1,nexternal
      write (*,'(i2,1x,5e15.7)') i, P(0,i),P(1,i),P(2,i),P(3,i),dsqrt(dabs(DOT(p(0,i),p(0,i))))
      enddo
C
      CALL SLOOPMATRIX(P,MATELEM)
C
      write (*,*) "-------------------------------------------------"
      write (*,*) "Matrix element = ", MATELEM(1,0), " GeV^", -(2*nexternal-8)
      write (*,*) "-------------------------------------------------"

After "make check" command, it reported the following error:

gfortran -w -fPIC -ffixed-line-length-132 -o check check_sa.o MadLoopParamReader.o MadLoopCommons.o polynomial.o loop_matrix.o improve_ps.o CT_interface.o loop_num.o helas_calls_ampb_1.o mp_compute_loop_coefs.o mp_helas_calls_ampb_1.o coef_construction_1.o coef_construction_2.o coef_construction_3.o loop_CT_calls_1.o loop_CT_calls_2.o mp_coef_construction_1.o mp_coef_construction_2.o mp_coef_construction_3.o TIR_interface.o compute_color_flows.o -L../../lib/ -ldhelas -lmodel -L../../lib/ -lcts -liregi -L/Users/sphe/Software/MG5_aMC_v3_5_3/HEPTools/lib/ -lninja -L/Users/sphe/Software/MG5_aMC_v3_5_3/HEPTools/lib/ -lavh_olo -lc++ -mmacosx-version-min=10.8
Undefined symbols for architecture arm64:
  "_sloopmatrix_", referenced from:
      _MAIN__ in check_sa.o
     (maybe you meant: _ml5_0_sloopmatrix_thres_, _ml5_0_sloopmatrix_ )
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
make: *** [check] Error 1

I am not sure whether it is caused by the inconsistencies of gfortran in ARM architecture. Then, how to solve this bug?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I also have another question. It seems that the amplitude is averaged over all helicity and colour configurations, then how to fix a specific helicity configuration?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

My computer is MacBook Air with Apple M1 and the OS is macOS Ventura.

The gcc version is as follows:
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

The gfortran version is "GNU Fortran (Homebrew GCC 13.2.0) 13.2.0".

The MadGraph version is "MG5_aMC_v3_5_3".

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Best,
Shi-Ping He

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Best Olivier Mattelaer (olivier-mattelaer) said :
#1

This does not seem anything mac specific (since the code compile the first time)
I would follow the suggestion of the compiler and change the line
      CALL SLOOPMATRIX(P,MATELEM)
by
      CALL ml5_0_sloopmatrix(P,MATELEM)

Cheers,

Olivier

Revision history for this message
Shi-Ping He (shi-pinghe) said :
#2

Thanks Olivier Mattelaer, that solved my question.