**Next message:**Vladyslav Shtabovenko: "Re: Possible bug in OneLoop"**Previous message:**Vladyslav Shtabovenko: "Re: Re: Bug for replacing in GS[p] and SPD[k, p]?"**Maybe in reply to:**Sascha T.: "Additional Bug to #4 in OneLoop or PaVeReduce?"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

More than 8 years have passed and this question remained unanswered. Oh well...

So the point here is that at the end OneLoop converts momenta and metric tensors to 4 dimensions, which is fine if is the very final stage of the calculation, butof course not fine if the output of OneLoop will be reused for further calculations in DR.

In particular, in your example contracting the 4-dim output of OneLoop (containing 4-dim metric tensors) with D-dimensional metric tensor gives you 4s instead of Ds, which is the source of the discrepancy. If you pay attention to that, you will get the correct result

LoopFunc =

FVD[q, \[Mu]] FVD[

q, \[Nu]] FAD[{q, Subscript[m, 0]}, {q + Subscript[p, 1],

Subscript[m, 1]}]

test1 = OneLoop[q, Contract[MTD[\[Mu], \[Nu]] LoopFunc],

OneLoopSimplify -> False] // ChangeDimension[#, D] &

test2 = Contract[

MTD[\[Mu], \[Nu]] ChangeDimension[

OneLoop[q, LoopFunc, OneLoopSimplify -> False], D]]

diff = PaVeReduce[(test1 - test2)]

gives 0.

This actually prompts me to introduce strict dimension checking in Contract (like I did in TID), as unless you use the BMHV scheme, there is no way you will be contracting two metric tensors with different dimensions.

So it was a good question, pity that it didn't get answered earlier.

Cheers,

Vladyslav

*> Hello,
*

*>
*

*> I tried to find a general expression for a tensor integral using
*

*> Feyncalc. To test the result, I performed an especially easy
*

*> contraction where one can calculate the result by hand. Unfortunately
*

*> I reproduced the result only up to an additional summand of 1/2.
*

*>
*

*> I then tried to find where I made a mistake. Finally I figured out
*

*> that there is obviously a problem with Feyncalc. Maybe it is related
*

*> to Bug #4, but it is somehow different.
*

*>
*

*> Using the following mathematica code, the problem becomes obvious
*

*> already in this very simple case:
*

*>
*

*> LoopFunc =
*

*> FVD[q, \[Mu]] FVD[q, \[Nu]]
*

*> FAD[{q, Subscript[m, 0]}, {q + Subscript[p, 1], Subscript[m, 1]}]
*

*>
*

*> test1 =
*

*> OneLoop[q,
*

*> Contract[MTD[\[Mu], \[Nu]] LoopFunc ,
*

*> OneLoopSimplify -> False] ]
*

*>
*

*> test2 = Contract[
*

*> MTD[\[Mu], \[Nu]] OneLoop[q, LoopFunc,
*

*> OneLoopSimplify -> False] ]
*

*>
*

*> diff = PaVeReduce[(test1 - test2)]
*

*>
*

*> Can you please comment on this. Maybe it is already known. Or you can
*

*> advice me, what I should not do using these functions since I do not
*

*> know why this problem occurs.
*

*>
*

*> best regards,
*

*> Sascha
*

**Next message:**Vladyslav Shtabovenko: "Re: Possible bug in OneLoop"**Previous message:**Vladyslav Shtabovenko: "Re: Re: Bug for replacing in GS[p] and SPD[k, p]?"**Maybe in reply to:**Sascha T.: "Additional Bug to #4 in OneLoop or PaVeReduce?"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

*
This archive was generated by hypermail 2b29
: 02/16/19-08:20:01 AM Z CET
*