Add `Flat` attribute to `SmallVariable`

[JP-Ellis]

This ensure that SmallVariable[SmallVariable[x]] == SmallVariable[x], which I've had appear a few times in certain calculations.

[vsht]

Hmm, I would rather be interested to trace the origin of these SmallVariable[SmallVariable[x]] and fix that, since this is not something that should appear in the output.

There are also not so many places in the code where SmallVariables come into play. I suspect it must be something in PaVeIntegrals.m, PaVeReduce.m or PaVeOrder.m.

Would it be possible to reduce your calculation(s) to a minimal working example that reproduces the issue?

[JP-Ellis]

It was a left-over I noticed from some previous calculations. I believe it came about from defining certain particle masses with SmallVariable with a combination of using the SmallVariables option (as it wasn't clear how it ought to be used).

Unfortunately, I no longer have an example of this happening except for the fact that I added to Flat attribute still in some parts of my code. Although to someone who knows how FeynCalc is meant to work it may not be useful to have the Flat attribute, but having it might just avoid some simple issues by other users?

[vsht]

I see. It appears that this behavior is quite easy to reproduce e.g. by writing

se = SmallVariable[ME];
re = OneLoop[q, FVD[q, mu] FAD[{q, 0}, {q + p2, se}, {q + p3, se}], 
   SmallVariables -> {ME}] // FCE

which yields

-I \[Pi]^2 (-FV[p2, mu] PaVe[
     1, {SP[p2, p2], SP[p2, p2] - 2 SP[p2, p3] + SP[p3, p3], 
      SP[p3, p3]}, {0, SmallVariable[SmallVariable[ME]]^2, 
      SmallVariable[SmallVariable[ME]]^2}, PaVeAutoOrder -> True, 
     PaVeAutoReduce -> True] - 
   FV[p3, mu] PaVe[
     2, {SP[p2, p2], SP[p2, p2] - 2 SP[p2, p3] + SP[p3, p3], 
      SP[p3, p3]}, {0, SmallVariable[SmallVariable[ME]]^2, 
      SmallVariable[SmallVariable[ME]]^2}, PaVeAutoOrder -> True, 
     PaVeAutoReduce -> True])

And this is certainly not the way how it is supposed to be. Furthermore, the reason why it comes out this way is here

https://github.com/FeynCalc/feyncalc/blob/43799615251583455b0318add7b4dee84acd8f25/FeynCalc/LoopIntegrals/OneLoop.m#L285

So I'd rather suggest that you create a pull request to fix this bug in OneLoop. Then there is no need to deal with nested SmallVariables, since they will never appear in the output.

What I have in mind, is that one extracts all arguments of SmallVariables occurring in oneamp via Cases and then filters the smallv list with sth like smallv=SelectFree[smallv,args].

And of course one would need at least one unit test for Tests/LoopIntegrals/OneLoop.test to ensure that we won't reintroduce this bug in the future.

[vsht]

Hope you are not grumpy, but in the past I already has some bad experiences with attaching new attributes to basic objects. Luckily that came up when some unit tests failed, otherwise I would have broken workflows of quite some people. This taught me to be more cautious, especially when turning "wrong" looking output into something that lookd "right". At the end of the day, if the output is weird, it is either because of a bug or because the user input is somehow inconsistent. In the former case this is something to fix on the FeynCalc side. In the latter case, one should better tell the user how to avoid such mistakes in the future.

[JP-Ellis]

I doubt this would have broken any workflow, and hopefully unit tests would have fixed this. In any case, I'll close this for now.