FCLoopFindMomentumShifts Unable to identify valid shift #362

adisurtya · 2026-06-19T19:52:50Z

adisurtya
Jun 19, 2026

Hello!

I have two topologies here:

topo1=FCTopology["fctopology1Rx7", {FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p5, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p5 - p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p3 - p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p2 + p3 - p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p2 + p3 - p5, D], 0, 0, {1, 1}]]}, {p5, p6}, {p2, p3}, {Hold[Pair][Momentum[p2, D], Momentum[p2, D]] -> 0, Hold[Pair][Momentum[p3, D], Momentum[p3, D]] -> 0, Hold[Pair][Momentum[p4, D], Momentum[p4, D]] -> 0, Hold[Pair][Momentum[p2, D], Momentum[p4, D]] -> s24/2, Hold[Pair][Momentum[p3, D], Momentum[p4, D]] -> s34/2, Hold[Pair][Momentum[p2, D], Momentum[p3, D]] -> s23/2}, {FCGV["SubtopologyOf"] -> "fctopology1"}];

topo2=FCTopology["fctopology2Rx7", {FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p5, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p5 - p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p2 - p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p2 + p3 - p6, D], 0, 0, {1, 1}]], FeynAmpDenominator[StandardPropagatorDenominator[Momentum[p2 + p3 - p5, D], 0, 0, {1, 1}]]}, {p5, p6}, {p2, p3}, {Hold[Pair][Momentum[p2, D], Momentum[p2, D]] -> 0, Hold[Pair][Momentum[p3, D], Momentum[p3, D]] -> 0, Hold[Pair][Momentum[p4, D], Momentum[p4, D]] -> 0, Hold[Pair][Momentum[p2, D], Momentum[p4, D]] -> s24/2, Hold[Pair][Momentum[p3, D], Momentum[p4, D]] -> s34/2, Hold[Pair][Momentum[p2, D], Momentum[p3, D]] -> s23/2}, {FCGV["SubtopologyOf"] -> "fctopology2"}];

and am doing:

FCLoopFindMomentumShifts[{topo1},topo2]

which yields:

FCLoopFindMomentumShifts: Failed to derive the momentum shifts between topologies fctopology1Rx7 and fctopology2Rx7. Possibly due to no valid shifts, nonquadratic propagators, or required external momentum shifts.

It is unable to find the valid shift:
shift = {p5 -> p2 + p3 - p5, p6 -> p2 + p3 - p6};

My understanding is that it identifies the two topologies are related via the external momenta exchange {p2->p3, p3->p2}; however, the routine fails to identify the additional shift involving only loop momenta. I also tried specifying:

FCLoopFindMomentumShifts[{topo1},topo2, Momentum -> {p5, p6} ]. But this does not change anything.

In general, this issue seems to occur whenever there exists a (forbidden) external momenta shift that exists, and there may or may not be additional, loop-momenta only shifts. Is there any other options I can set or other work arounds to be able to identify these kinds of shifts? Thanks in advance!

vsht · 2026-06-20T15:29:10Z

vsht
Jun 20, 2026
Maintainer

Hi,

first of all, FCLoopFindMomentumShifts assumes that the propagators are already ordered in the 1-to-1 correspondence using Pak algorithm. In this sense it is actually an auxiliary function. What you are might be looking for is FCLoopFindTopologyMappings. However, in this case it also won't find more shifts.

It is unable to find the valid shift:
shift = {p5 -> p2 + p3 - p5, p6 -> p2 + p3 - p6};

what exactly do you mean with p5 -> p2 + p3 - p5, p6 -> p2 + p3 - p6} being a valid shift?
If you apply it two both topologies, there's still a difference between two propagators, one being p6-p2 and another p6-p3.

FCReplaceMomenta[topo1, {p5 -> p2 + p3 - p5, p6 -> p2 + p3 - p6}]
FCReplaceMomenta[topo2, {p5 -> p2 + p3 - p5, p6 -> p2 + p3 - p6}]
%[[2]] - %%[[2]]

My understanding is that it identifies the two topologies are related via the external momenta exchange {p2->p3, p3->p2}; however, the routine fails to identify the additional shift involving only loop momenta

If there's a shift that only involves loop momenta, then for quadratic propagators it should be detectable without further issues.
But as I wrote above, at the moment I don't see how the shift you suggest maps one topology to the other one.

The Momentum option is only for enabling shifts in external momenta, which are not applied by default unless explicitly requested by the user. So with

FCLoopFindMomentumShifts[{topo1}, topo2, Momentum -> {p2, p3}]

or

FCLoopFindMomentumShifts[{topo1}, topo2, Momentum -> All]

You get the shifts in p2,p3 that you mentioned.

2 replies

adisurtya Jun 20, 2026
Author

Hello, thanks for the quick response! Yes, I was initially using FCLoopFindTopologyMappings, but took a look at FCLoopFindMomentumShifts to debug. Here is what I mean that the routine is missing a valid shift.

First, apply the shift to topo2 (I don't understand why you are applying the shift to both topologies in your response):
topo2Shifted = FCReplaceMomenta[topo2, shift]

Then compare the propagators, after reordering and simplifying:
(FDS /@ topo2Shifted[[2]])[[{5, 6, 3, 4, 1, 2}]] - (FDS /@ topo1[[2]]),
which outputs:
{0, 0, 0, 0, 0, 0}.

Thank you!

vsht Jun 21, 2026
Maintainer

Hi,

ok, now I see your point. The issue is indeed a bit more subtle.

Pak algorithm is guaranteed to find a mapping between two equivalent sets of propagators, but
it does not make any statements on how this mapping will be realized via momentum shifts. This
is also not surprising, since while ordering the Feynman parameters $x_i$, the algorithm works with
a momentum free representation.

Now for practical purposes one naturally wants a shift that only involves changing loop momenta.
By selecting the very first ordering of propagators found by Pak one assumes that it will be the most
useful one. Heuristically, mostly it happens to be true, but there are also more pathological cases (like yours)
where this choice only allows for (useless) shifts in external momenta.

As far as I know, there is no guarantee, that if a shift in external momenta exists, there must be another
shifts involving loop momenta only. But it is likely, so one could check for that. However, this will also
take more time, since instead of blindly taking the first ordering, one now has to check every ordering
until a useful shift is found. And in the worst case none will exist.

I made a small commit to the master branch to allow for selecting the ordering by hand. This can be used to illustrate
the situation:

topo1Pak = 
 FCLoopFindIntegralMappings[{topo1}, 
     Select -> Function[{x}, x[[1]]]][[1]][[1]] // Last

topo2Pak = 
 FCLoopFindIntegralMappings[{topo2}, 
     Select -> Function[{x}, x[[2]]]][[1]][[1]] // Last

FCLoopFindMomentumShifts[{topo1Pak}, topo2Pak]
(* {{p5->p2+p3-p5,p6->p2+p3-p6}} *)

But I need to ponder a bit more on how to add it to FCLoopFindTopologyMappings in a proper way.
Obviously as a separate option, since it will cost some extra performance.

TBH, I never bothered too much about having the most minimal set of families, since doing reduction
on a cluster (like in Karlsruhe) is cheap enough and at the end you anyhow will minimize the number of
masters. So this issue did not seem to be so pressing to me.

But I do recognize that it is an enhancement worth adding to the code.

Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FeynCalc

FCLoopFindMomentumShifts Unable to identify valid shift #362

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Sunbelt Computer Software

PL/B Language Development and Support

FeynCalc

FCLoopFindMomentumShifts Unable to identify valid shift #362

Uh oh!

Uh oh!

adisurtya Jun 19, 2026

Replies: 1 comment · 2 replies

Uh oh!

vsht Jun 20, 2026 Maintainer

Uh oh!

adisurtya Jun 20, 2026 Author

Uh oh!

vsht Jun 21, 2026 Maintainer

adisurtya
Jun 19, 2026

Replies: 1 comment 2 replies

vsht
Jun 20, 2026
Maintainer

adisurtya Jun 20, 2026
Author

vsht Jun 21, 2026
Maintainer