Problems with some boxes in QCDLoop

[jnl89]

I am playing around with QCDLoop and had so far a very good impression of performance and stability.
For more complicated processes, however, I find no agreement with other tools such as OneLoop or Collier.
For example, I encounter a problem with the following massless box configuration with 3 onshell lines (p2,p3,p4) for hard kinematics:

 p1_2 =-521247.510219513904303312301635742
 p2_2 =0.00000000000000000000000000000000
 p3_2 =6463.99920100000053935218602418900
 p4_2 =0.00000000000000000000000000000000
 p12_2=-471395.374060058966279029846191406
 p23_2=8543.51790217262896476313471794128

For mu=1, OneLoop (ba57666) returns for the finite part:

  (-4.86539890373703392E-009,1.67822293416622610E-009)

while QCDLoop (af35d18) yields:

  (-4.86539890373703414235078743072e-09,3.62745344717407615900139594223e-08)

i.e. the real part perfectly agrees, but the imaginary part seems wrong since I find agreement between OneLoop and Collier.

Here a sample program for comparing oneloop:

program main
  use avh_olo
  implicit none
  integer, parameter :: prec = kind(1d0)
  real(prec) :: mu = 1d0
  real(prec) :: rescalef = 1._prec
  complex(prec) :: p1_2,p2_2,p3_2,p4_2,p12_2,p23_2,m12,m22,m32,m42
  complex(prec) :: rslt1(0:2),rslt2(0:2)

  call olo_scale_prec(mu)

  p1_2 =-521247.510219513904303312301635742_prec
  p2_2 =0.00000000000000000000000000000000_prec
  p3_2 =6463.99920100000053935218602418900_prec
  p4_2 =0.00000000000000000000000000000000_prec
  p12_2=-471395.374060058966279029846191406_prec
  p23_2=8543.51790217262896476313471794128_prec


  m12 =0._prec
  m22 =0._prec
  m32 =0._prec
  m42 =0._prec


  call olo(rslt1,p1_2,p2_2,p3_2,p4_2,p12_2,p23_2,&
    m12,m22,m32,m42)

  rescalef = 17.01_prec
  call olo_scale_prec(mu*rescalef)
  p1_2=p1_2*rescalef**2
  p2_2=p2_2*rescalef**2
  p3_2=p3_2*rescalef**2
  p4_2=p4_2*rescalef**2
  p12_2=p12_2*rescalef**2
  p23_2=p23_2*rescalef**2

  m12 = m12*rescalef**2
  m22 = m22*rescalef**2
  m32 = m32*rescalef**2
  m42 = m42*rescalef**2

  call olo(rslt2,p1_2,p2_2,p3_2,p4_2,p12_2,p23_2,&
    m12,m22,m32,m42)
  !
  write(*,*) "rslt1:", rslt1(0)
  write(*,*) "rslt2:", rslt2(0)*rescalef**4
  write(*,*) "box precision:", real(rslt1(0)/rslt2(0),prec)/rescalef**4 - 1
  !QCDLoop result: 
  ! -4.86539890373703414235078743072e-09 + I * 3.62745344717407615900139594223e-08
end program m

Cheers,
Jean-Nicolas

[scarrazza]

Thanks for reporting this issue. As soon as I have some time I will look at this, but meanwhile could you please post the code you are using for QCDLoop? Did you try qcdloop v1?

[jnl89]

I haven't tried qcdloop v1.
I played a bit more with the case at hand and noticed that I get the correct result using a different permutation of the invariants.
The following permutation fails

std::vector<ql::qcomplex> res(3);
std::vector<ql::qcomplex> m(4);
std::vector<ql::qdouble> p(6);

m[0] = 0;
m[1] = 0;
m[2] = 0;
m[3] = 0;

ql::qdouble mu = 1;

p[0] = -521247.510219514022679732079268;
p[1] = 0;
p[2] = 6463.99920100000049982824634753;
p[3] = 0;
p[4] = -471395.374060059074196260553435;
p[5] = 8543.51790217263162574568013952;


const ql::QCDLoop<ql::qcomplex,ql::qcomplex,ql::qdouble> qcdloop_qp;
qcdloop_qp.integral(res, mu, m, p);
std::cout << "res[0]: " << std::setprecision(32) << res[0] << std::endl;

yielding

`(-4.86539890373703431297152881401123e-09,3.62745344717407872154503412984827e-08)`

while

std::vector<ql::qcomplex> res(3);
std::vector<ql::qcomplex> m(4);
std::vector<ql::qdouble> p(6);

m[0] = 0;
m[1] = 0;
m[2] = 0;
m[3] = 0;

ql::qdouble mu = 1;

p[0] = 0;
p[1] = 6463.99920100000049982824634753;
p[2] = 0;
p[3] = -521247.510219514022679732079268;
p[4] = 8543.51790217263162574568013952;
p[5] = -471395.374060059074196260553435;

const ql::QCDLoop<ql::qcomplex,ql::qcomplex,ql::qdouble> qcdloop_qp;
qcdloop_qp.integral(res, mu, m, p);
std::cout << "res[0]: " << std::setprecision(32) << res[0] << std::endl;

gives the expected result obtained with oneloop and collier (both of which are independent of the permutation of invariants):

`(-4.86539890373703431297152881401121e-09,1.67822293416622550385099346350847e-09)`

I can give you more input if needed. Thanks for looking into this.