Name: Vladyslav Shtabovenko (email_not_shown)
Date: 05/19/17-12:44:06 PM Z


Dear Ula,

I apologize, I'm afraid I skimmed through your code only
very briefly and overlooked that you already define L and
R as GA[6] and GA[7], instead of first using the sole symbols in the
calculation.

On the other hand, now I'm afraid that I'm not able to reproduce your
wrong result. With FeynCalc 9.2 this (now without DeclareNonCommutative)

R = GA[6];
L = GA[7];
yiPR = YiPR L + YiPRCC R;
ys1 = Ys1 L + Ys1CC R;
ys2 = Ys2 L + Ys2CC R;
SetMandelstam[s, t, u, p1, p2, -q1, -q2, mc1, mc2, ms1, ms2];

AmpSquare =
   Tr[yiPR.(GS[p1] - mc1 ID).ys1.(GS[p2 - q2] + mb ID).ys2.(GS[p2] +
        mc2 ID)] // Simplify;

ID = 1; Res1 = AmpSquare

Clear[ID, Res2]
ID = GA[6] + GA[7];
Res2 = AmpSquare

(Res1 - Res2) // Simplify
% // DiracSimplify[#, DiracSubstitute67 -> True] &

yields 0 as it should (c.f. the attached notebook)

As to your second comment, in FeynCalc there are no explicit Dirac
indices, and hence no special unit matrix in the Dirac space.
This means, that when you compute a Dirac trace, all the Dirac matrices
should be spelled out explicitly.

Otherwise you get such strange results with Dirac matrices remaining
after the trace. Here the issue is really that FeynCalc does not know
what is ID and assumes it to be a c-number, i.e. something free of Dirac
matrices.

Again, you could do

R = GA[6];
L = GA[7];
yiPR = YiPR L + YiPRCC R;
ys1 = Ys1 L + Ys1CC R;
ys2 = Ys2 L + Ys2CC R;

SetMandelstam[s, t, u, p1, p2, -q1, -q2, mc1, mc2, ms1, ms2];
DeclareNonCommutative[ID];

AmpSquare =
  DiracTrace[
   yiPR.(GS[p1] - mc1 ID).ys1.(GS[p2 - q2] + mb ID).ys2.(GS[p2] +
      mc2 ID), DiracTraceEvaluate -> True]

However, in this case DiracTrace will abort evaluation, once it
encounters a trace over ID that it does not know how to handle.

Cheers,
Vladyslav

Am 19.05.2017 um 12:15 schrieb Ula:
> Dear Vladyslav,
>
> I don't have much experience with FeynCalc (I hope this will change soon), maybe that is why I don't understand why should I use DeclareNonCommutative[L, R]. I mean, L and R are just abbreviations for internal FeynCalc objects (I was using SetDelayed in my definitions of AmpSquare).
>
> I checked that with your tip it works correctly, but, to be honest, the fact that Res2 still depends on chiral projectors is even more strange.
>
> Best regards,
> Ula
>
>
>
>
>> Dear Ula,
>>
>> in this case you are missing a declaration of L and R
>> as noncommutative quantities.
>>
>> By default, FeynCalc will treat every symbol that has not been
>> explicitly declared to be noncommutatuve, as a c-number. The following
>> works fine
>>
>> DeclareNonCommutative[L, R]
>> R = GA[6];
>> L = GA[7];
>> yiPR = YiPR L + YiPRCC R;
>> ys1 = Ys1 L + Ys1CC R;
>> ys2 = Ys2 L + Ys2CC R;
>> SetMandelstam[s, t, u, p1, p2, -q1, -q2, mc1, mc2, ms1, ms2];
>>
>> AmpSquare =
>> Tr[yiPR.(GS[p1] - mc1 ID).ys1.(GS[p2 - q2] + mb ID).ys2.(GS[p2] +
>> mc2 ID)] // Simplify;
>>
>> ID = 1; Res1 = AmpSquare
>>
>> Clear[ID, Res2]
>> ID = GA[6] + GA[7];
>> Res2 = AmpSquare
>>
>> (Res1 - Res2) // DiracSimplify[#, DiracSubstitute67 -> True] &
>>
>> Here DiracSubstitute67 merely replaces GA[6] and GA[7] by their
>> explicit values, i.e. 1/2(1+GA[5]) and 1/2(1-GA[5]) respectively.
>> Otherwise the difference is proportional to (GA[6]+GA[7]-1)
>>
>> Cheers,
>> Vladyslav
>>
>>
>> Am 19.05.2017 um 11:24 schrieb Ula:
>>> Dear Vladyslav,
>>>
>>> Thanks for the fast reply and your great work with FeynCalc. I checked that many examples with chiral projectors indeed yield correct results now, but not all of them. In the example below, Res1 is consistent with my own calculations.
>>>
>>> (*Definitions*)
>>>
>>> In[2]:= R = GA[6];
>>>
>>> In[3]:= L = GA[7];
>>>
>>> In[4]:= yiPR = YiPR L + YiPRCC R;
>>>
>>> In[5]:= ys1 = Ys1 L + Ys1CC R;
>>>
>>> In[6]:= ys2 = Ys2 L + Ys2CC R;
>>>
>>> In[7]:= SetMandelstam[s, t, u, p1, p2, -q1, -q2, mc1, mc2, ms1, ms2];
>>>
>>> In[8]:= AmpSquare :=
>>> Tr[yiPR.(GS[p1] - mc1 ID).ys1.(GS[p2 - q2] + mb ID).ys2.(GS[p2] +
>>> mc2 ID)] // Simplify;
>>>
>>> (*Correct Result*)
>>>
>>> In[9]:= ID = 1; Res1 = AmpSquare;
>>>
>>> (*Wrong Result*)
>>>
>>> In[10]:= Clear[ID, Res2]
>>>
>>> In[11]:= ID = GA[6] + GA[7]; Res2 = AmpSquare;
>>>
>>> (*Difference*)
>>>
>>> In[12]:= Res1 - Res2 // Simplify
>>>
>>> Out[12]= mc2 (2 mc1^2 + mc2^2 + ms2^2 - s - u) (YiPR Ys1 Ys2 +
>>> YiPRCC Ys1CC Ys2CC)
>>>
>>>
>>> All the best,
>>> Ula
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> thanks for the bug report. It is a bug that affects terms like
>>> (L1 GA[7] + R1 GA[6]) where both projectors appear multiplied with
>>> different constants. Should be now fixed. Please reinstall FeynCalc 9.2
>>> and let us know if you encounter any further issues.
>>>
>>> Cheers,
>>> Vladyslav
>>>
>>> Am 17.05.2017 um 11:02 schrieb Ula:
>>>> Dear FeynCalc users,
>>>>
>>>> In ``official" FeynCalc examples the identity matrix is not used under the trace. However, it seems that sometimes this yields wrong results when chiral projectors are present. Is this an expected bahavior, or I am doing something wrong? (I'm using FeynCalc 9.2.0 with Mathematica 8.0.4.)
>>>>
>>>> (*Definitions*)
>>>>
>>>> In[2]:= ID = GA[6] + GA[7];
>>>>
>>>> In[3]:= y1 = L1 GA[7] + R1 GA[6];
>>>>
>>>> In[4]:= y2 = L2 GA[7] + R2 GA[6];
>>>>
>>>>
>>>> (*Worng result*)
>>>>
>>>> In[5]:= Tr[y1.(GS[p2] + m2).y2.(GS[p1] - m1)] // FCE
>>>>
>>>> Out[5]= -2 (L2 R1 + L1 R2) (m1 m2 - SP[p1, p2])
>>>>
>>>> (*Correct result*)
>>>>
>>>> In[6]:= Tr[y1.(m2).y2.(-m1)]
>>>>
>>>> Out[6]= -2 m1 m2 (L1 L2 + R1 R2)
>>>>
>>>>
>>>> (*Correct result*)
>>>>
>>>> In[7]:= Tr[y1.(GS[p2] + m2 ID).y2.(GS[p1] - m1 ID)] // Simplify // FCE
>>>>
>>>> Out[7]= -2 m1 m2 (L1 L2 + R1 R2) + 2 (L2 R1 + L1 R2) SP[p1, p2]
>>>>
>>>>
>>>> Thanks and best wishes,
>>>> Ula
>>>>
>>>
>




This archive was generated by hypermail 2b29 : 09/04/20-12:55:05 AM Z CEST