Recursion error during numerical evaluation of box diagram

[tonymenzo]

For background - I am attempting to numerically compute one loop amplitude contributions in the mass insertion approximation for a one-to-three decay process. To get a feel for the algorithm I am computing the decay rate for just one diagram. My idea was to use FeynCalc's TID function to first rewrite the amplitude (which I have written out explicitly) in terms of Passarino-Veltman scalar integrals and then use the following substitution rule

toLT := {FeynCalc`PaVe[i__Integer, {p___}, {m___}, O___] -> 
    LoopTools`PaVe[i, ToExpression["{" <> ToString[p] <> "}"], 
     ToExpression["{" <> ToString[m] <> "}"]], 
   FeynCalc`D0[X___] -> LoopTools`D0[X], 
   FeynCalc`C0[X___] -> LoopTools`C0[X] , 
   FeynCalc`A0[X___] -> LoopTools`A0[X], 
   FeynCalc`B0[X___] -> LoopTools`B0[X] };

to evaluate these functions numerically using LoopTool's. This seems to work as expected, after substituting the relevant numerical factors I end up with a lengthy summation of spinor-gamma matrix blocks. The next natural step, in my mind, is to obtain the spin-averaged squared amplitude using the FermionSpinSum function. Upon doing so I seem to run into an infinite loop with errors

$RecursionLimit::reclim2: Recursion depth of 1024 exceeded during evaluation of \[Not]OptionQ[{}].
$RecursionLimit::reclim2: Recursion depth of 1024 exceeded during evaluation of {}==={}.
$RecursionLimit::reclim2: Recursion depth of 1024 exceeded during evaluation of Hold[\[Not]OptionQ[{}]].
General::stop: Further output of $RecursionLimit::reclim2 will be suppressed during this calculation.
$IterationLimit::itlim: Iteration limit of 4096 exceeded.
$IterationLimit::itlim: Iteration limit of 4096 exceeded.
$IterationLimit::itlim: Iteration limit of 4096 exceeded.
General::stop: Further output of $IterationLimit::itlim will be suppressed during this calculation.

I have been unable to find a solution to this problem. My thought is that maybe FeynCalc's internal language is getting tangled when I evaluate PaVe's with LoopTools. I have not been able to find the origin of the OptionQ[...] even after looking at the stack.

I have attached a notebook which contains my code. If you have any suggestions/corrections/comments on my implementation they would be much appreciated. Also, if you need any other information let me know.

I am using Mathematica 12.1 with FeynCalc 9.3.1 and LoopTools 2.15 on a Manjaro system.

recursiveErrorBoxDiagram.zip

[vsht]

As a quick idea (I didn't look at the code yet) you may try

toLT := {FeynCalc`PaVe[i__Integer, {p___}, {m___}, O___] -> 
    LoopTools`PaVe[i, ToExpression["{" <> ToString[p] <> "}"], 
     ToExpression["{" <> ToString[m] <> "}"]], 
   FeynCalc`D0[X___,OptionsPattern[]] -> LoopTools`D0[X], 
   FeynCalc`C0[X___,OptionsPattern[]] -> LoopTools`C0[X] , 
   FeynCalc`A0[X___,OptionsPattern[]] -> LoopTools`A0[X], 
   FeynCalc`B0[X___,OptionsPattern[]] -> LoopTools`B0[X] };

BTW, I had an idea of a proper LoopTools interface via FeynHelpers,
but it got stalled due to a lack of public interest and potential testers.

https://github.com/FeynCalc/feynhelpers/blob/looptools/Interfaces/LoopTools.m

If you are interested, I could try to revamp it over the weekend.

[tonymenzo]

OptionsPattern[] didn't fix the recursive issue but I think it's a good idea to have it in there generally.

If you're up to it yeah, that looks like it would be great and prove quite useful for me. I'd be happy to put it through the wringer.

[vsht]

Now that I had a look at this again, I remember that FeynCalc and LoopTools cannot be naively loaded on the same kernel:
as both define same symbols (e.g. A0, B0 etc.) you get all kind of weird shadowing errors. You would see these errors
if you wouldn't apply Quiet to Install. BTW, if you get any errors/warnings in conjunction with FeynCalc, in 99% of cases
this signals that something gone wrong and you will get garbage as output. So it's a very bad idea to ignore those.

If you save the output of FeynCalc into a separate file and then load it on a fresh kernel (without loading FeynCalc there) with LoopTools, this should probably work.

I'm attaching a short example for using the LoopTools interface from the dev version of FeynHelpers.

https://github.com/FeynCalc/feynhelpers#development-version

See if it works for you. However, please keep in mind that LoopTools has a lot of options and I'm not an expert on that. You can
set them via the interface functions, though.

LoopToolsExample.zip

[alessandrovalenti]

Hello @vsht , sorry to open again this old discussion. I need to evaluate numerically some B0,C0,D0 functions obtained through Feyncalc. I downloaded the development version of FeynHelper, however it is not working on my system, I think because I am on Windows.
Are there any way to evaluate the result numerically through looptools beside installing Linux? For instance, I tried copypasting the result in a new notebook in which I loaded only LoopTools, however because of the different output representation (B_0 in Feyncalc, B0 in LoopTools for instance) I cannot make evaluate the result. Do you have any suggestions?
Thanks,
Alessandro

[vsht]

Ok, since I assume that you understand what you are doing, that's fine with me.

Still, for LToolsEvaluate I would like to assume that the input expressions is an amplitude linear
in PaVe functions. Your case of evaluating PaVe^2 that all turn out to be IR and UV finite seems to
be too special to deserve a dedicated treatment. So let us focus on evaluating the amplitude first
and squaring thereafter.

Indeed, as Tony correctly guessed, most FeynCalc functions will freak out when given input containing floating
point numbers. So we better wrap the evaluated PaVe functions with some arbitrary head and keep them
in that state until the very end when the amplitude squared is a pure c-number made of scalar products,
evaluated integrals and other constants. To that end I added a new option Head to LToolsEvaluate. This way your
example seems to work fine

Example2.zip

If you want to compare numerical results to the output of Package-X, I would recommend using
the newly introduced FCCompareNumbers routine.

As to polarization sums, I'll try to update the documentation to include some d-dim examples in due time.

Cheers,
Vladyslav

[alessandrovalenti]

Thank you Vladyslav, and sorry for the delay of the answer. Indeed the functionality that you have implemented works well! This solves my problems. Thank you again, and have a good day!

[vsht]

Nice to hear that. I've updated the documentation pages on PolarizationVector, PolarizationSum and DoPolarizationSums
to mention D-dimensional polarizations. You can access them from the overview

https://github.com/FeynCalc/feyncalc/blob/master/FeynCalc/DocumentationFiles/Markdown/Extra/FeynCalc.md

of the current frugal documentation (due to reasons explained in #59, the documentation in FC 10 will be completely
markdown based and built out of pages in DocumentationFiles/Markdown)

[alessandrovalenti]

Many thanks! If you do not mind, let me ask a last question. As I was stating some messages ago, my amplitude is both UV and IR finite. Indeed if I compute the cross section (i.e. 1-loop amplitude squared, since is a process not present at tree-level) analytically, I get a decent result: a "compact" expression written in terms of the functions C0^2 , C0xD0, D0^2, with all the particles massive. At this point it would be very nice if I could simply expand these functions analytically (via package x) or numerically (LoopTools), avoiding some of the problems encountered before. However PaXEvaluate and LToolsEvaluate do not handle C0^2, C0xD0 and D0^2. At the moment I am looking at the file Interfaces/PackageX.m in order to enable this functionality: indeed package-x alone handles the square of PaVe functions, through LoopRefine[]. But I do not have any experience in advanced Mathematica programming. So my question is: can you point me to what needs to be modified in order for this to work?
Thank you and good evening.

[vsht]

I'm afraid that the Package-X interface would require too many modifications to be able to handle squared 1-loop integrals.
Essentially, it would be probably easier to rewrite it from scratch.

In a such situation I would probably try to do all loop-related expansions on the amplitude level and then expand again when needed upon having calculated the squared amplitude.