Name: Vladyslav Shtabovenko Date: 05/04/17-05:44:45 PM Z

Dear FeynCalc users,

it is well known, that using several Mathematica packages doing similar
things on the same kernel often leads to shadowing issues.

For example, a lot of high energy physics packages introduce functions
like Contract, FourVector, DiracMatrix etc., which subsequently clash
with the definitions of these functions in FeynCalc.

Normally, my solution to this is either to rename
offending functions in the other packages (as it is done with FeynArts),
or to write an interface to those packages, so that one access their
functions via new names (as it is done in FeynHelpers).

Recently, I was made aware of the fact, that sometimes people would like
to use a specific package on the same kernel with FeynCalc but to do it
in such a way, that their existing codes for that package can work
without any changes.

Suppose that a package XYZ defines “Pair” and “DiracGamma”, which makes
it inherently incompatible with FeynCalc. If you prefer not to change
your existing codes for package XYZ, you could, in principle, patch
FeynCalc to rename Pair and DiracGamma to something else. Of course,
this makes your instance of FeynCalc incompatible to all the existing
codes and addons. On the other hand, the patched FeynCalc will work as
usual, with the exception that whenever you need to access Pair or
DiracGamma, you must remember to use different names.

Now it is possible to patch FeynCalc on-the-fly while loading the
package, i.e. the changes in the names of FeynCalc functions are not
persistent and the source code of FeynCalc on your hard drive is not
modified. Once you restart the kernel, everything will be as it was.

Certainly, this functionality is meant only for people who very well
understand what they are doing. Yet, if the conflicting FeynCalc
function is something that you anyhow never use, this trick can still be
quite useful.

You also have to keep in mind, that if your package XYZ modifies the
default behavior of Mathematica’s functions and variables in some
non-trivial way, it might still be incompatible with FeynCalc, even
though there will be now shadowing issues.

Anyhow, the magic variable (now available in the development version) is
“$RenameFeynCalcObjects”

Some examples:

1) Load FeynCalc and Package-X on the same kernel

$RenameFeynCalcObjects = {“Contract” -> “FCContract”,
    ”DiracMatrix” -> “FCDiracMatrix”};
«FeynCalc`
«X`

Notice that now FeynCalc completely ignores Contract and DiracMatrix

DiracMatrix[\[Gamma].p1 + me \[DoubleStruckOne],
   Subscript[\[Gamma], \[Mu]], \[Gamma].p2 - me \[DoubleStruckOne],
   Subscript[\[Gamma], \[Nu]]] // Tr
DiracMatrix[\[Gamma].p1 + me \[DoubleStruckOne],
   Subscript[\[Gamma], \[Mu]], \[Gamma].p2 - me \[DoubleStruckOne],
   Subscript[\[Gamma], \[Nu]]] // Spur
Contract[Subscript[k, \[Mu]] Subscript[k, \[Mu]]]
FCContract[FV[k, mu] FV[k, mu]]

2) Load FeynCalc and Tracer on the same kernel

$RenameFeynCalcObjects = {“Eps” -> “FCEps”};
«FeynCalc`
«Tracer`

?Eps

Eps[arg1,arg2,arg3,arg4] is the completely antisymmetric product of
the four arguments “arg1-4”. Eps[] is multi-linear with respect to
a linear combination with scalar coefficients. Arguments of Eps[]
can be a mixture of Lorentz indices and momenta, e.g.
“Eps[[p,{mu},q,{nu}]” means “Eps_{alpha mu beta nu} p^alpha q^beta”
in a standard physics notation.

3) Load FeynCalc and FIRE on the same kernel

$RenameFeynCalcObjects = {“Contract” -> “FCContract”};
«FeynCalc`
«FIRE5`

4) Load FeynCalc and S@M at the same kernel

$RenameFeynCalcObjects = {“Schouten” -> “FCSchouten”,
    ”Gamma1” -> “FCGamma1”, “Gamma2” -> “FCGamma2”,
    ”Gamma3” -> “FCGamma3”};
«FeynCalc`
$SpinorsPath =
   FileNameJoin[{$UserBaseDirectory, “Applications”, “Spinors”}];
«Spinors`

Happy FeynCalc hacking ;)

Cheers,
Vladyslav