Dear Ula,
nevermind, I got your point and I finally realized what was going wrong
here. Many thanks for your bug report, reinstalling FeynCalc (again)
should fix the issue. Your original code
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
now works as it should. This
Clear[ID]
DeclareNonCommutative[ID]
Res3 = (AmpSquare /. ID -> 1 /. DiracTrace -> Tr) // Simplify
Res4 = (AmpSquare /. ID -> GA[6] + GA[7] /. DiracTrace -> Tr) //
Simplify
Res1 - Res3 // Simplify
Res1 - Res4 // Simplify
works as well.
Cheers,
Vladyslav
Am 19.05.2017 um 13:11 schrieb Ula:
> Dear Vladyslav,
>
> I was using
>
> AmpSquare := Tr[...]
>
> (rather than =), so in your case ID is unknown to FeynCalc at the time of evaluation.
>
> I also guess that the Dependence of Res2 on GA[] was somehow caused by DeclareNonCommutative -- in my original example Res2 was a ``number", as it should be, even though it was a wrong number.
>
> Thanks and best wishes,
> Ula
>
>> 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