Closed HBelusca closed 6 years ago
Sorry for the late reply. I usually rely on the GitHub e-mail notifications to be informed about new issues, but for some strange reason none was generated in your case. So I noticed this one just today rather by accident. Very weird :(
It is a bug in the symmetrizer part, that should be now fixed. Sorry again for the trouble.
Cheers, Vladyslav
Thanks! I will close the issue as soon as I will find time to re-test with your fix.
Re. GitHub, I think it was due to a problem they had at the very time I created that issue; I remember having encountered a spurious connection problem.
Cheers, Hermès
Hello Vladyslav, I confirm that the main problem is now fixed! However I detected a new bug that comes when building or solving the system of equations, see issue #37.
Best, Hermès
11.2.0 for Microsoft Windows (64-bit) (September 11, 2017)
9.3.0 (development) (154268bb6edd4fc701a0127af60245ac572d63ff)
When performing a 2-loop tensor reduction using
FCMultiLoopTID
I noticed that unevaluated symbolsFeynCalc`Tdec`Private`CC
were returned in the result.The loop integral in question is (q1,q2 are the loop momenta and k1 is an external momentum):
After some investigations I managed to find that the
Tdec
function generated theseCC
symbols. The corresponding Tdec call is:Looking further I noted that for the tensor reduction, 14 different "CC" symbols are generated, then a system of 14 equations is built. The problem that happens there is that only 11 of these 14 equations appear to be independent, the other ones are redundant, and as a result only 11 "CC" symbols can be solved. The remaining 3 are the ones that show up in the final result.
I attach in the compressed ZIP archive two notebooks with Tdec verbosity level enabled, one with this example and another one with a different example that works on the contrary (for comparison purposes):
Tdec[{{q2, mu1}, {q1, mu2}, {q1, mu3}, {q1, mu4}}, {k1} , UseTIDL->False]
.Tdec_issue.zip