The dreaded mixture of 4- and D-dimensional quantities error

[peterblunden]

Attached is a simple example of the kind of problems I'm having with FeynCalc 9.3 using Mathematica 12.0. My old FeynCalc could do this without a hitch. I figured out how to do this in D dimensions by changing ScalarProduct to D dimensions using ChangeDimension, but I want to do it in 4 dimensions to avoid huge output expressions.

1. I can't figure out what is the D-dimensional quantity that is causing the error. Is there a way to force D=4 everywhere?
2. OneLoop had a nice feature of Prefactor and SmallVariables. Is there an equivalent for TID?
   Any help would be appreciated.

FCtest.pdf

[vsht]

Attached is a simple example of the kind of problems I'm having with FeynCalc 9.3 using Mathematica 12.0. My old FeynCalc could do this without a hitch. I figured out how to do this in D dimensions by changing ScalarProduct to D dimensions using ChangeDimension, but I want to do it in 4 dimensions to avoid huge output expressions.

1. I can't figure out what is the D-dimensional quantity that is causing the error. Is there a way to force D=4 everywhere?

By "D=4 everywhere" you probably mean calculating a D-dimensional amplitude in D-dimensions and then taking the limit
D->4 using the known UV-pole structure of PaVe-functions and assuming that any IR poles present in the amplitude are
mass regularized?

Even in this case the input should still be D-dimensional, to avoid issues such as

http://www.feyncalc.org/forum/1115.html

and similar inquiries we received via e-mails in the past. This is why we decided that
FeynCalc functions should better not fiddle with the dimensionality of the user input.
The user input is what it is and if the chosen dimensions do not look consistent, it is better
to issue a warning rather than trying to "fix" it behind the scenes as in FeynCalc 8.2 and older.

Still, you raise a valid point. Let me modify your example a bit to demonstrate the difference
between TID and OneLoop

<< FeynCalc`
$LimitTo4 = True;
kp = ScalarProduct[k, p];
den = FAD[{k, \[Lambda]}, {p - k, 0}];
den4 = ChangeDimension[den, 4]

TID[ChangeDimension[kp den FV[k, mu] FV[k, nu], D], k]

OneLoop[k, ChangeDimension[kp den FV[k, mu] FV[k, nu], D], 
 Dimension -> 4]

Here OneLoop produces a simpler looking input by exploiting the encoded UV-properties
of PaVe-functions. Personally, I never liked this way of taking the D->4 limit and would insist
on having the full D-dependence in the prefactors. However, I'm not the only person using FC
and I recognize that this functionality was present in OneLoop from version 1.0 and is currently
missing in TID.

My idea would be to implement it as a separate routine, say PaVeLimitTo4 that can be called
standalone or in the final stage of TID. Since we have PaVeUVPart that can extract UV poles
from arbitrary PaVe functions, this should actually be rather easy to implement. Let me have a look
at this.

2. OneLoop had a nice feature of Prefactor and SmallVariables. Is there an equivalent for TID?
   Any help would be appreciated.

FCtest.pdf

Prefactor is easy to add, SmallVariables would require some work. Nevertheless, both are obviously
needd.

[vsht]

Ok, I added a new function PaVeLimitTo4 that does what you like

https://github.com/FeynCalc/feyncalc/blob/master/FeynCalc/LoopIntegrals/PaVeLimitTo4.m#L20

TID can call it at the end of the calculation to achieve output similar to OneLoop with $LimitTo4
and $LimitTo4IRUnsafe set to True. For that one needs to set the options ToPaVe and PaVeLimitTo4
of TID to True.

The Prefactor option is now also available.

You can install the dev version and try it out

kp = SPD[k, p];
den = FAD[{k, \[Lambda]}, {p - k, 0}];
res = TID[kp den FVD[k, mu] FVD[k, nu], k, ToPaVe -> True, 
  PaVeLimitTo4 -> True, Prefactor -> XYZ]
res // FCE // StandardForm

-(1/(24 SP[p, p]^2))
  I \[Pi]^2 XYZ PaVe[
    0, {}, {\[Lambda]^2}] (4 \[Lambda]^4 FV[p, mu] FV[p, nu] + 
     8 \[Lambda]^2 FV[p, mu] FV[p, nu] SP[p, p] - \[Lambda]^4 MT[mu, 
       nu] SP[p, p] + 
     4 FV[p, mu] FV[p, nu] SP[p, p]^2 + \[Lambda]^2 MT[mu, nu] SP[p, 
       p]^2 - MT[mu, nu] SP[p, p]^3) + (1/(24 SP[p, p]^2))
 I \[Pi]^2 XYZ PaVe[
   0, {SP[p, p]}, {0, \[Lambda]^2}] (\[Lambda]^2 + 
    SP[p, p]) (4 \[Lambda]^4 FV[p, mu] FV[p, nu] + 
    4 \[Lambda]^2 FV[p, mu] FV[p, nu] SP[p, p] - \[Lambda]^4 MT[mu, 
      nu] SP[p, p] + 4 FV[p, mu] FV[p, nu] SP[p, p]^2 + 
    2 \[Lambda]^2 MT[mu, nu] SP[p, p]^2 - 
    MT[mu, nu] SP[p, p]^3) - (1/(144 SP[p, p]))
 I \[Pi]^2 XYZ (12 \[Lambda]^4 FV[p, mu] FV[p, nu] + 
    8 \[Lambda]^2 FV[p, mu] FV[p, nu] SP[p, p] - 
    3 \[Lambda]^4 MT[mu, nu] SP[p, p] - 
    4 FV[p, mu] FV[p, nu] SP[p, p]^2 - 
    8 \[Lambda]^2 MT[mu, nu] SP[p, p]^2 + 4 MT[mu, nu] SP[p, p]^3)

The support for SmallVariables is trickier to implement, but I'll put it on my agenda.

[vsht]

Just in case someone is using PaVeLimitTo4, I'd be glad to hear some feedback and learn about
possible shortcomings that need to be addressed.

The theoretical underpinning for using the "D->4 method" despite possible presence of IR-poles
in truncated diagrams can be found e.g. on slides 32-35 of this talk by A. Denner

https://th-workshop2009.desy.de/e59393/e59359/infoboxContent59362/Denner.pdf

This is supposedly the origin of the presence of $LimitTo4 in FeynCalc (the corresponding ideas
were worked out around 1990 or so, the linked talk just summarizes later developments).

However, since I usually prefer to keep all poles in my calculations, I don't use this technology
in practice. But I'm still willing to support it within FeynCalc :)