Divergent Part Calculation

[wedelfach]

Hallo,

I'm calculating a divergent part of the amputated amplitudes generated by FA. The amplitudes originate from one-loop diagrams in some efficient gauge theory. Currently my program converts amplitudes from FC to FA, contracts and simplifies them. Then in applies: TID, ToPaVe, and PaVeUVPart. All this works correctly, but TID and PaVeUVPart are not very fast. I have to admit, that may expressions is rather long (~1000 terms) but the integrals are not very sophisticated. I'd like to ask, is there any way to speed up this procedure? Or maybe there is an alternative way to exctarct UV part using FeynCalc? I'm interested in purely symbolic answer.

I'm using Mathematica 11.0 (Student Edition), FeynCalc 9.3.1 and FeynArts 3.11.

[vsht]

Is TID being used with the UsePaveBasis option? PaVeUVPart works on arbitrary PaVe-functions,
not just the scalar ones.

[wedelfach]

Thank You once again, now I have better view. By the way is it possible to group terms proportional to the same loop integrals (exactly as TID is doing) but without performing any other operations?

[vsht]

Sure. Consider e.g.

lis = Table[Unique[], {i, 1, 6}];
fads = {FAD[{q, m0}], FAD[{q + p1, m1}], FAD[{q + p2, m2}], 
   FAD[{q + p3, m3}], FAD[{q + p4, m4}]};
makeNum[] := 
  FCI[Times @@ Thread[FVD[q, lis[[1 ;; RandomInteger[6]]]]]];
makeDen[] := 
  FeynAmpDenominatorCombine[
   Times @@ RandomSample[fads, RandomInteger[{1, 5}]]];
makePref[] := 
 Sum[RandomInteger[10] x^RandomInteger[10], {i, 1, 5}]/
  Sum[RandomInteger[10] x^RandomInteger[10], {i, 1, 5}]
amp = Sum[makePref[] makeNum[] makeDen[], {i, 1, 100}];

Then one could start collecting things in multiple ways

AbsoluteTiming[
 ampCollected = 
   Collect2[amp, FeynAmpDenominator, q, Factoring -> {Factor, 5000}, 
    TimeConstrained -> 3];]

AbsoluteTiming[
 ampCollected = 
   Collect2[amp, FeynAmpDenominator, Factoring -> {Factor, 5000}, 
    TimeConstrained -> 3];]

The Factoring and TimeConstrained option tell Collect2 not to bother with factoring the prefactors if the LeafCount is higher than 5000 or if the operation requires more than 3 seconds. These are my empiric defaults that seem to fit most QFT calculations. The reason for doing this is that sometimes Mma's Factor gets too confused with complicated prefactors and wastes too much time on them. In Mma 12.2 WRI fixed some Factor bugs that I discovered there, so Factor is sort of "cool again". On older Mma versions I'd probably use FC's Factor2 instead.

If you need to temporarily hide the complexity by looking only at certain parts of the expression, use IsolateNames and IsolateFast (and FRH when you want to unisolate)

ampIsolated = 
 Collect2[amp, FeynAmpDenominator, q, IsolateNames -> KK, 
  Factoring -> False, IsolateFast -> True]


ampIsolated[[1]]
% // FRH

There are also more specific functions for extracting unique loop integrals from the given amplitude that were introduced in
Sec. 3.4 of 1601.01167. So

FCLoopExtract[amp, {q}, loopInt]

is also a possible choice. If you need to work with amplitudes that contain not only FAD-integrals but also PaVe-Integrals, use
FeynCalcPackagePaVeHeadsList for the list of all possible PaVe-heads.

[wedelfach]

Thank You very much. I found out that the code works also almost 4 times faster if it is called directly from console.

[vsht]

Can it be that you are entering your commands without a ";" in the front-end?

The point is that rendering large expressions in the front-end can be very time consuming.
It is also easy to construct cases where the actual evaluation proceeds much faster than the rendering afterwards
E.g.

AbsoluteTiming[res = Table[i^2, {i, 1, 10^8}];]

vs

AbsoluteTiming[res = Table[i^2, {i, 1, 10^8}]]

Here you loose a lot of time just because you want to see the intermediate expression
(which is anyhow too large to deduce anything useful out of it).

The front-end is undoubtedly a useful thing, but one has to use it wisely. BTW, it is also
easy to ruin all the performance gains in FORM, by putting a lot of .sort commands here
and there thus forcing the compiler to "simplify" the whole expression instead of looking at
it term-by-term as FORM usually does.

Large-scale computations are not just about a powerful language or a lot of CPU power and RAM,
one also has to design the codes in such a way, that computationally expensive operations occur
only when needed, i.e. at right places and nowhere else.

EDIT: Sorry, I actually wanted to have 10^8 instead of 10^6 in my original example. But it seems that
the 10^8 case never terminates on Mma 12.2 (bug?) Anyway, I think that you got my point :)

[wedelfach]

Of course, I use semicolons at the end of each line. But thank You for your adivce about the .sort command.

[vsht]

Ok then. Although it's still not entirely clear to me, how you get a 4-fold speed increase by using
the kernel instead of the front-end. Provided that the Mma versions are the same in both cases.