Skip to content

LiteRed's FindSymmetries and the EMs option again

Hi,

I'm having another issue with LiteRed's FindSymmetries. This code

Internal={k, l};
External={p1, p2};
Propagators={k^2 - mt^2, k^2 - mt^2 + 2*k*p2, k^2 - mt^2 + 2*k*p1 + 2*k*p2 + s, l^2 - mt^2 + 2*l*p1 + 2*l*p2 + s, l^2 - mt^2 + 2*l*p2, l^2 - mt^2, k^2 - 2*k*l + l^2};
Replacements={p1^2 -> 0, p2^2 -> 0, p1*p2 -> s/2};
Quiet[CreateNewBasis[topology, Directory->FileNameJoin[{Directory[],"LR"}]], {DiskSave::overwrite,DiskSave::dir}];
Quiet[GenerateIBP[topology], FrontEndObject::notavail];
Quiet[AnalyzeSectors[topology], FrontEndObject::notavail];
Quiet[FindSymmetries[topology, EMs->True], FrontEndObject::notavail];
Quiet[DiskSave[topology], {DiskSave::overwrite,DiskSave::dir}];

not only throws some warnings

Solve::svars: Equations may not give solutions for all "solve" variables.

Solve::svars: Equations may not give solutions for all "solve" variables.

Solve::svars: Equations may not give solutions for all "solve" variables.

General::stop: Further output of Solve::svars will be supprSolve::svars: Equations may not give solutions for all "solve" variables.

Solve::svars: Equations may not give solutions for all "solve" variables.

Solve::svars: Equations may not give solutions for all "solve" variables.

General::stop: Further output of Solve::svars will be suppressed during this calculation.essed during this calculation.

but also generates jRules with internal symbols, like

{j[topology, (n1_)?NonPositive, (n2_)?Positive, (n3_)?NonPositive, 
    (n4_)?NonPositive, (n5_)?Positive, (n6_)?NonPositive, (n7_)?Positive] /; 
   True :> Expand[j[topology, 0, 0, n5, n2, 0, 0, n7]/
    ((j[topology, 0, -1, 0, 0, 0, 0, 0]/LiteRed`Private`m$5541[2, 4] + 
       (j[topology, 0, 0, -1, 0, 0, 0, 0]*(-1 + LiteRed`Private`m$5541[2, 
           4]))/LiteRed`Private`m$5541[2, 4])^n6*
     (j[topology, 0, 0, 0, 0, -1, 0, 0]/LiteRed`Private`m$5541[2, 4] + 
       (j[topology, 0, 0, 0, -1, 0, 0, 0]*(-1 + LiteRed`Private`m$5541[2, 
           4]))/LiteRed`Private`m$5541[2, 4])^n1*
     (j[topology, 0, 0, -1, 0, 0, 0, 0] - j[topology, -1, 0, 0, 0, 0, 0, 0]*
        LiteRed`Private`m$5541[2, 4] + j[topology, 0, -1, 0, 0, 0, 0, 0]*
        LiteRed`Private`m$5541[2, 4] + s*j[topology, 0, 0, 0, 0, 0, 0, 0]*
        LiteRed`Private`m$5541[2, 4])^n4*(j[topology, 0, 0, 0, -1, 0, 0, 0] + 
       j[topology, 0, 0, 0, 0, -1, 0, 0]*LiteRed`Private`m$5541[2, 4] - 
       j[topology, 0, 0, 0, 0, 0, -1, 0]*LiteRed`Private`m$5541[2, 4] + 
       s*j[topology, 0, 0, 0, 0, 0, 0, 0]*LiteRed`Private`m$5541[2, 4])^n3)]}

which make FIRE crash when doing the reduction.

LiteRed 2 from Roman's repository doesn't seem to have any issues with this topology, but it doesn't help much here, since FIRE still requires 1.8x.

Yes, once could use EMs->{} to bypass the issue, but then the reduction is less efficient performance-wise so it's not a feasible workaround.

The topology itself is from gg -> H at 2-loops via a top triangle, where all particles are on-shell. So it's not really something ground-breaking or highly nontrivial, where one might expect unusual behavior.