WIP - Add support for 1-loop PaVe's that can be described using Package-X functions having different Weights.
Add support for evaluating with Package-X 1-loop integrals that have same repeated propagators and that can be described by X`PVA, X`PVB, X`PVC or X`PVD with different Weights.
We are now able to evaluate e.g. E0[0,0,k1^2,0,k1^2,0,k1^2,k1^2,k1^2,k1^2,0,0,0,0,0]
that now becomes translated into X`PVB[0, 0, k1.k1, 0, 0, Weights->{3,2}].
This is currently work-in-progress. The solution presently implemented supports only functions whose GenPaVe form currently have "zero-indices". A reduction for the more general case is still "unknown". Advice on this patch would be much welcome.
Are there actually any other packages that implement weighted PaVe's or is this a pure Package-X invention? If one would like to cross check the results numerically, this could be problematic. LoopTools certainly doesn't support such things. Does Collier?
Personally I never needed such stuff since I would rather IBP reduce everything with "weights" to arrive to the standard PaVe's. The only situation where this becomes problematic are zero Gram determinant cases. Then one has to fiddle a bit with FIRE, but at the end you still can get your normal PaVe's.
So I'd like to understand in which calculations those weighted PaVe's are really required.
If you can reduce everything to E0 and alike (i.e. no coefficient functions, just scalars),
why not handle them with IBPs?
The "weights" concept seems (at least introduced like that) to be an "invention" of Package-X in order to have under the same PVA/B/C/D name these class of 1-loop integrals where the same propagator is present with higher powers. If I recall correctly, LoopTools can deal with these E0 functions. In my case I obtained these sort of integrals by calculating a 1-loop purely gluonic gluon box in generic R-xi gauge (and other less complicated diagrams, but still with gluon propagators in R-xi gauge), while trying to use only FeynCalc TID + PaX interface. (I haven't used these more sophisticated packages like Collier et al. . Note also that in my case I'm mostly interested in analytical formulae.)
I mentioned Collier because one usually would like to check the obtained analytical results numerically for several points. Just to be sure that the analytic result is correct. If you have integrals written in a basis for which no numerical evaluations are available, such checks become problematic.
I recognize the issue, but my personal approach would be to address it by
- Providing a function that can convert PaVe's back to FAD's.
- Improving the interface to FIRE so that integrals are grouped by topologies and C++ reduction is used by default.
The first point is problematic (within FeynCalc) in the case of vanishing Gram determinants. This is something that should be definitely resolved for FeynCalc 10.