vermaseren / form

The FORM project for symbolic manipulation of very big expressions
GNU General Public License v3.0
1.14k stars 136 forks source link

Color package doesn't manage contraction of 3 structure constants and 5 generators #96

Closed antoncyrol closed 8 years ago

antoncyrol commented 8 years ago

Working with FORM's color package (which I took from here), we discovered a problem/bug while contracting three structure constants and five generators. To be more specific, I see the color package's internal notation like cOlpR1 and cOlpA. I have created a minimal example that demonstrates the problem:

color_package_bug.zip

For SU(N), I can circumvent this problem, see the example file. I didn't know where to report this issue. If the appropriate place is FORM's forum, please re-direct me.

Thank you very much in advance, any help is greatly appreciated!

All the best, Anton

More info: I'm using FORM 4.1 (Jan 13 2014) 64-bits, downloaded the binary from here.

vermaseren commented 8 years ago

Hi,

I checked a bit, but the two expressions are identical when you substitute the values for the quartic object as it is in SU(N). You can try this out by running the SUn procedure and making a separate expression that gives you the quartic object. It is a bit of playing around. If you are only interested in SU(N) all these higher Casimir’s can be expressed in terms of N, but you cannot try to construct the general formula that is good for all groups and representations from that. You can run the attached program to see things with SU(N) and then try to run the second expression with color.h which gives just the quartic term (without the i_).

Jos

On 23 mei 2016, at 11:00, Anton Konrad Cyrol notifications@github.com wrote:

Working with FORM's color package (which I took from here http://www.nikhef.nl/%7Eform/maindir/packages/color/color.html), we discovered a problem/bug while contracting three structure constants and five generators. To be more specific, I see the color package's internal notation like cOlpR1 and cOlpA. I have created a minimal example that demonstrates the problem:

color_package_bug.zip https://github.com/vermaseren/form/files/277122/color_package_bug.zip For SU(N), I can circumvent this problem, see the example file. I didn't know where to report this issue. If the appropriate place is FORM's forum, please re-direct me.

Thank you very much in advance, any help is greatly appreciated!

All the best, Anton

More info: I'm using FORM 4.1 (Jan 13 2014) 64-bits, downloaded the binary from here http://www.nikhef.nl/%7Eform/maindir/binaries/binaries.html.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/vermaseren/form/issues/96

vermaseren commented 8 years ago

I am not sure the attachment came through. Here it is again:

test.zip

Jos

antoncyrol commented 8 years ago

Hi Jos, thank you for your quick reply. Unfortunately, I still have a couple of questions:

Is it correct that your proposed solution holds for general representations and not only the fundamental representation as our solution does? Do you recommend using the specialized SU(N) algorithm instead of the general one?

We are working on QCD. Thus, the SU(N) workaround in the fundamental representation suffices us. However, we are developing a general-purpose Mathematica tracing package that heavily relies on FORM and the color package. For this a general solution would be nice. Do you know whether a general tracing result exists for the given expression?

vermaseren commented 8 years ago

Dear Anton,

The general expression is what FORM gives. In general you cannot reduce the pR.pA^4 and others. If you know however more about your group (like SU(N)) and the R representation (quarks), you can, for that case, make further reductions and express everything in powers of N. To express it in terms of cR and cA is a bit of a cheat as it suggest greater generality than there is. For groups like SO(N) such expressions are different. Etc. If you are only interested in SU(N) the easiest is to use the SUn routine that I included. You get your expression in terms of N and the routine is very simple. It is based on the Cvitanovic paper.

I am not sure what you mean with a “general tracing result”. The answer that the program gives is the general trace. It is just that the program is not entirely simple (although with the newer FORM commands it can be made a lot shorter) and hence nobody has copied it yet. Unlike the harmonic sums. When you do a complicated calculation of for instance splitting functions, it is best in my opinion to do this for a general group/representation. If you compute crosssections, you better take it as soon as possible to SU(3). This is not always true, because sometimes the more general result will give you some extra physics information of course.

I hope this helps a bit

Jos

On 24 mei 2016, at 19:51, Anton Konrad Cyrol notifications@github.com wrote:

Hi Jos, thank you for your quick reply. Unfortunately, I still have a couple of questions:

Is it correct that your proposed solution holds for general representations and not only the fundamental representation as our solution does? Do you recommend using the specialized SU(N) algorithm instead of the general one?

We are working on QCD. Thus, the SU(N) workaround in the fundamental representation suffices us. However, we are developing a general-purpose Mathematica tracing package that heavily relies on FORM and the color package. For this a general solution would be nice. Do you know whether a general tracing result exists for the given expression?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/vermaseren/form/issues/96#issuecomment-221346338

antoncyrol commented 8 years ago

Dear Jos,

by "general tracing result" I meant a group independent expression in terms of casimirs which I erroneously thought to exist. Thus, I wrongly believed that pR.pA^4 is not the final result. Thank you for clarifying this. We'll work with the general algorithm when possible/required and use your SU(N) algorithm otherwise.

Thank you for your detailed answer, Anton