[GiNaC-list] Performance of simplify_indexed on long chains of Dirac matrices
v.shtabovenko at tum.de
Sun Jan 4 18:53:51 CET 2015
I didn't have a look at the source code yet, but as far as I know, there
are essentially two ways to simplify D-dimensional Dirac matrix chains
of type g^mu ... g_mu (if there are more, I'm always eager to learn)
1) By repeatedly applying the anticommutation relations to move g_mu
through all other matrices to g^mu. This is the easiest but also the
slowest way to implement.
2) By using a recursion formula as found in Veltman's Gammatrica
or in Rolf Mertig's FeynCalc paper. This improves the performance but
still can take much time for long chains.
One can speed up the recursion formula even further by caching the
results that have already been computed. In Mathematica language that's
called "memoization". This technique is used e.g. in FeynCalc.
Since simplify_indexed doesn't have many analogues in other HEP tools
(people mostly care only about traces), it might be reasonable to look
at the performance of dirac_trace instead. With GiNaC this
takes around 5 seconds on my machine, a similar code with FORM
AutoDeclare Indices i;
Local M2 = g_(1,i1,i2,i3,i4,i5,i6,i7,i1,i2,i3,i4,i5,i6,i7);
requires less than 0.01 seconds. With FeynCalc
$LoadPhi = False;
$LoadTARCER = False;
$LoadFeynArts = True;
Tr[GAD[i1, i2, i3, i4, i5, i6, i7].GAD[i1, i2, i3, i4, i5, i6,
i7]] // AbsoluteTiming
I get the result in 0.007 seconds.
So I think that it would be very nice if someone of the GiNaC developers
could have a look at this issue.
Am 04.01.2015 um 13:29 schrieb Vladimir V. Kisil:
> Dear Vladyslav,
>>>>>> On Sun, 04 Jan 2015 00:48:23 +0100, Vladyslav Shtabovenko <v.shtabovenko at tum.de> said:
> VSh> I'm wondering about the performance of simplify_indexed applied
> VSh> to a long chain of Dirac matrices in D dimensions.
> You raised a valid concern. Let me provide some
> background. Historically, GiNaC was dealing with Dirac matrices
> associated to the Lorentz metric only. At some point the code was
> expanded to treat an algebra with a general commuting/anticommuting
> relation between generators. Since the generality reduced performance,
> the original code optimised for Dirac matrices was preserved as much
> as possible.
> I checked your example, it did not call to general time-consuming
> cliffordunit::contract_with(), canonicalize_clifford() and
> get_metric(). Instead, it (as it is supposed to do) made numerous
> calls to clifford::eval_ncmul() and diracgamma::contract_with(). I
> believe that the later two functions are mainly as they were in the
> original GiNaC code optimised for Dirac matrices.
> So, a further investigation of the code is required....
> Best wishes,
More information about the GiNaC-list