Using FeynArts/FormCalc for single diagram evaluation

  • Thread starter Thread starter brodekind
  • Start date Start date
  • Tags Tags
    Diagram
Click For Summary

Discussion Overview

The discussion revolves around the use of the FormCalc package in conjunction with FeynArts for evaluating Feynman diagrams, specifically focusing on the challenges encountered when calculating the squared amplitude for single diagrams in tree-level processes involving vector bosons. Participants explore the discrepancies between results obtained from FormCalc and manual calculations, particularly regarding gauge field polarizations.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant notes that FormCalc works well for complete tree-level processes but fails when evaluating individual diagrams, particularly those involving vector bosons.
  • Another participant requests clarification on what "fails" means and suggests sharing a test notebook to investigate the issue further.
  • A participant describes their attempt to calculate the squared amplitude using a modified polarization sum, which resulted in a discrepancy by a factor of 6 compared to manual calculations.
  • Concerns are raised regarding the treatment of gauge fields in FormCalc, with one participant noting that the results for single diagrams without gauge fields do not exhibit the same issues.
  • One participant discusses the importance of averaging over initial polarizations and summing over final states for vector bosons, suggesting that this could complicate the calculations.
  • Another participant asserts that the issue is not related to normalization or averaging, as they believe FormCalc should yield a specific result that it does not.

Areas of Agreement / Disagreement

Participants express differing views on the source of the discrepancies in results, with no consensus reached on whether the issue lies in normalization, averaging, or the treatment of gauge fields in FormCalc.

Contextual Notes

Participants mention specific configurations and options used in FormCalc, such as "GaugeTerms->False" and modifications to the PolarizationSum.frm file, indicating that the discussion is highly technical and dependent on specific coding practices and assumptions.

brodekind
Messages
5
Reaction score
0
Hi folks,

I was wondering if someone knows enough about the FormCalc package to help me out: I am using FeynArts to generate Feynman-diagrams for certain tree-level processes and FormCalc to calculate the squared amplitude of these processes (http://en.misho-web.com/phys/feynlecture.html gives some neat examples on how this is done). Now this works fine if one considers all tree-level-diagrams, i.e. the complete process at tree level, but fails when only evaluating one of several diagrams (e.g. just calculating the squared 4-vertex-diagram of the gluon+gluon -> gluon+gluon process, instead of all squared diagrams and interference terms).
My first naive idea was that FormCalc might use identities which are correct only for physical processes (i.e. all diagrams to a certain order considered) and not on the single diagram level; but I don't know if such identities exist and furthermore I didn't find anything in the code (which is to advanced for me anyway).
If someone has an idea any hint would be appreciated.

Edit: Further testing showed that the problem seems to be related just to vectorbosons in initial or final states. Because of this I was playing aroung with changing the polarizationsum (in the PolarizationSum.frm) to -d_([mu],[nu]). However even in this configuration a single squared diagram including vectorbosons does not give the result one calculates via Feyman-rules per hand using this simplified polarizationsum. So the problem isn't just the introduction of gauge-dofs in single diagrams which cancel for the whole process.
 
Last edited:
Physics news on Phys.org
What do you mean by fails? Can you attach a test notebook? I use feyncalc and feynarts but not formcalc much. I have the code though to look at it. It DOES have massive vector spin sums built in right?

I'll take a look though.
 
Hi,

I attached a notebook with my calculation. So what I wanted to do there is calculate only the 4-vertex squared, using the sum over all gaugefield-polarizations equal to -gαβ instead of -gαβ+(some function involving a vector η perpendicular to physical polarizations). So I used the option "GaugeTerms->False" in the PolarizationSum call. But this does not give me the result I (and others) calculated when calculating the squared diagram with this reduced 'completeness relation' by hand; it's off by a factor of 6, and that's what I mean by "fails".
I tested that implementing the reduced 'completeness relation' in the form code in the file PolarizationSum.frm gives (for this calculation) the same result as using the option "GaugeTerms->False"; so it should give the result calculated by hand.

Now I am confused and curious as to what does FormCalc actually do for a single diagram involving initial or final gauge fields; the endresult for the whole process (without excluding internal lines) is exactly what you find in the literature. In addition, there seems to be no problem when calculating single diagrams without gaugefields in initial or final states, so this has to be related to the treatment of gaugefields.

On a sidenote: Curiously, using "GaugeTerms->False" does in general not reproduce the result with reduced 'completeness relation' in the PolarizationSum.frm file; for example in the s-channel diagram squared of the gg->gg process.
 

Attachments

  • VV.nb
    VV.nb
    68.5 KB · Views: 621
Hmm, doing it real fast by hand in feyncalc I get if I just sum over polarizations and indices, the 7776 g^4 you mention, BUT we're not SUMMING over all polarizations. When you have 2 incoming vector bosons you have to AVERAGE over initial polarizations, SUM over final, right? So there should be a factor of 1/3? for each of the incoming, correct? Or it might be more complicated than just merely (1/3)^2. I don't know if there is some argument to only taking the longitudinal/transverse part of each incoming polarization or whatnot.

Code:
AMP = (-I g^2) (SUNF[a, b, e].SUNF[c, d, 
        e].(MT[\[Alpha], \[Gamma]].MT[\[Beta], \[Delta]] - 
         MT[\[Alpha], \[Delta]].MT[\[Beta], \[Gamma]]) + 
      SUNF[a, c, e].SUNF[b, d, 
        e].(MT[\[Alpha], \[Beta]].MT[\[Gamma], \[Delta]] - 
         MT[\[Alpha], \[Delta]].MT[\[Gamma], \[Beta]]) + 
      SUNF[a, d, e].SUNF[b, c, 
        e].(MT[\[Alpha], \[Beta]].MT[\[Delta], \[Gamma]] - 
         MT[\[Alpha], \[Gamma]].MT[\[Delta], \[Beta]])) // Calc;
AMPCC = Calc[
   Calc[AMP] /. {a -> aa, b -> bb, c -> cc, d -> dd, 
     e -> ee, \[Alpha] -> \[Alpha]2, \[Beta] -> \[Beta]2, \[Delta] -> \
\[Delta]2, \[Gamma] -> \[Gamma]2}];
ASQ = SUNSimplify[(1/3)^2 Calc[
     AMP.AMPCC.(MT[\[Alpha], \[Alpha]2].MT[\[Beta], \[Beta]2].MT[\
\[Delta], \[Delta]2].MT[\[Gamma], \[Gamma]2].SUNDelta[a, aa].SUNDelta[
         b, bb].SUNDelta[c, cc].SUNDelta[d, dd])], 
   Explicit -> True] /. {CA -> 3, CF -> 4/3}

gives -864 g^4
 
Hi,

Thanks for looking into this. But I don't think it's an normalization/averaging problem.
Of course you're right: if you want to compute the averaged amplitude you have to sum over final and average over initial states (for vector bosons this means, dividing by a factor of (Nc^2-1)*2 for every initial boson, i.e. the number of gluons times the number of physical polarizations). But I didn't do that and FormCalc doesn't do this either for PolarizationSum and Bosons. Taking your calculation (and correcting the sign error taking the complex conjugate of I) without the averaging gives exactly 7776 g^4, the result FormCalc should give, but doesn't. I am fairly sure that this is the right result because taking all other diagrams for this process I calculated the invariant amplitude you'd find in the literature.
 

Similar threads

  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 5 ·
Replies
5
Views
3K
  • · Replies 16 ·
Replies
16
Views
4K
  • · Replies 7 ·
Replies
7
Views
4K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 1 ·
Replies
1
Views
4K
  • · Replies 0 ·
Replies
0
Views
3K
  • · Replies 40 ·
2
Replies
40
Views
5K
  • · Replies 2 ·
Replies
2
Views
3K