Allow jets of inhomogeneous color reps, e.g. u:ubar:gl

[sschmidt]

When using aliases, e.g.

alias finals = u:U:g

code generation for the process

process eef2 = e1, E1 -> finals, finals

that should equivalent to e1, E1 -> u U fails with the error message

| Calling O'Mega for process 'eef2'
| command: /localscratch/sschmidt/whizard/2.00_gfortran/bin/omega_SM.opt -o eef2.f90 -target:whizard -target:parameter_module parameters_SM -target:module eef2 -target:md5sum 341CE9C92AACAA320C7327B8CA5A353B -fusion:progress -scatter 'e- e+ -> u:ubar:gl u:ubar:gl'
Fatal error: exception Invalid_argument("Fusion.Colored.amplitudes: incompatible color representations")
*** Error: Process 'eef2': code generation failed

[sschmidt]

sample input file

[ohl]

O'Mega loudly complains that there's no 1 in 3x3 etc. Instead it should silently discard the combination. I will fix this.

[ohl]

Oops. Please disregard my previous comment. This has nothing to do with singlet vs. sextet or anti-triplet. It also has nothing to do with aliases

The process

e+ e- -> u:ubar:gl u:ubar:gl

is not equivalent to

e+ e- -> u ubar

but to

e+ e- -> u ubar
e+ e- -> ubar u

instead. In the latter we would have different color flows, which can not be combined in the current WHIZARD/O'Mega interface. With quarks in the initial state, we would even have octets.

[Juergen Reuter]

This needs at least some explanation: does this mean that I cannot properly define a jet as q:qbar:g ???

[kilian]

I don't get it either: I understand that we designed the W/O interface so that there is no such restriction. The array color_states lists all color combinations that occur, and each subprocess refers to those combinations that it contains in particular.

The only constraint is that in the final state, OMega should create uU only, while in the initial state, it should create uU + Uu.

[ohl]

OK, I see ...

[ohl]

Ok, I will implement it in full generality, but it's too late for RC1.

[ohl]

As of r1673, the code in the branch

svn+ssh://svn.hepforge.org/hepforge/svn/whizard/branches/ohl/omega-development/jets

is operational. In needs

• testing
• static initialization of the flv_col_allowed array
• improved diagnostics

before I can merge it into the trunk, but brave souls can start to play around with it.

[sschmidt]

my comments to the ohl/omega-development/jets-branch:

1) With r1688 for simple input files like

alias finals = u:U:g
process eef2 = e1, E1 -> finals, finals
compile

I get an error

libtool: compile:  gfortran -c -I/localscratch/sschmidt/whizard/2.00_gfortran/lib/whizard/mod/models -I/localscratch/sschmidt/whizard/2.00_gfortran/include/omega -I/localscratch/sschmidt/whizard/2.00_gfortran/lib/whizard/mod/whizard-core -I/localscratch/sschmidt/whizard/2.00_gfortran/lib/whizard/mod/misc -g -O2 eef2.f90  -fPIC -o .libs/eef2.o
eef2.f90:222.63:

    complex(kind=default) :: l1l1bu1b__1u1_1_, l1l1bu1b__1u1_1_
                                                               1
Error: Symbol 'l1l1bu1b__1u1_1_' at (1) already has basic type of COMPLEX

This was not the case in the previous version I had (r1687)

2) With r1687 I tested the processees

alias finals = u:U:g
process eef2 = e1, E1 -> finals, finals
process eef3 = e1, E1 -> finals, finals, finals
process eef4 = e1, E1 -> finals, finals, finals, finals

These processes work, but during compilation also nonexinsting processes are shown, e.g. for eef2

[1/4] e- e+ -> ubar//1 u/1/ ... done. [time: 0.03 secs, total: 0.11 secs, remaining: 0.08 secs]
[2/4] e- e+ -> ubar//1 u/1/ ... done. [time: 0.03 secs, total: 0.12 secs, remaining: 0.06 secs]
[3/4] e- e+ -> gl/1/2 gl/2/1 ... done. [time: 0.03 secs, total: 0.12 secs, remaining: 0.03 secs]
[4/4] e- e+ -> gl// gl// ... done. [time: 0.04 secs, total: 0.12 secs, remaining: 0.00 secs]
all processes done. [total time: 0.12 secs]

so it looks as if Omega compiles e+e- -> gg (and this takes as long as one of the other processes). I'm also a bit confused about the two identical e- e+ -> ubar1 u/1/ processes shown.

Numerical comparison shows that the results agree with the explicitly defined processes.

In the case

alias finals = u:U
process eef3 = e1, E1 -> finals, finals, finals

Omega finds no process

| command: /localscratch/sschmidt/whizard/2.00_nagfor//bin/omega_SM.opt -o eef3.f90 -target:whizard -target:parameter_module parameters_SM -target:module eef3 -target:md5sum 0109A8C66B895D21820B593DDA4A4FF8 -fusion:progress -scatter 'e- e+ -> u:ubar u:ubar u:ubar'
Fatal error: exception Invalid_argument("Progress.digits: non-positive argument")
*** Error: Process 'eef3': code generation failed

and therefore W2 fails when compiling

| Loading process library 'processes'
*** Fatal error:  Library 'processes': libtool archive not found

(Maybe this was to be fixed in r1688?)

[Juergen Reuter]

For me, taking a single forbidden process triggers a segmentation fault: Here is the backtrace:

| Loading process library 'processes'
Warning: Process 'foo': overwriting previous configuration
sqrts =    100.00000000000000
| Integrating process 'foo'

Program received signal SIGSEGV, Segmentation fault.
0x5845da0f in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0x5845da0f in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x5845f9ef in malloc () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e3b222 in __state_matrices_MOD_node_append_child () at state_matrices.f90:201
#3  0xb7e3b47a in node_make_branch.4532 () at state_matrices.f90:514
#4  0x088cc940 in ?? ()
#5  0xbf57b1ac in ?? ()
#6  0x083f3cbc in ?? ()
#7  0x00000000 in ?? ()

I attached the input file.

[Juergen Reuter]

input file triggering the seg fault

[ohl]

Replying to sschmidt:

it looks as if Omega compiles e+e- -> gg

That's normal, it just attempts it and returns almost immediately.

I'm also a bit confused about the two identical e- e+ -> ubar1 u/1/ processes shown.

That's a bug that also triggers the compilation error. Will fix it.

[ohl]

Replying to ohl:

Replying to sschmidt:

I'm also a bit confused about the two identical e- e+ -> ubar1 u/1/ processes shown.

That's a bug that also triggers the compilation error. Will fix it.

That was a really stupid one: my flavor ordering considered color singlets never as equal, e.g. e+ != e+ ... Fixed.

[ohl]

As of r1703, the code for inhomogeneous jets has been merged into the trunk. It has passed some simple tests (make check) and is ready for stress tests within Whizard.

Downgrading for P3/normal for testing.

[Juergen Reuter]

What kinds of tests are missing here, actually? Can't we move them into the standard validation ticket?

[ohl]

Added share/test/jets.sin in r1733. Closing this ticket.

[sschmidt]

Replying to ohl:

Replying to sschmidt:

it looks as if Omega compiles e+e- -> gg

That's normal, it just attempts it and returns almost immediately.

When compiling

alias j = u:U:d:D:g
! alias j = u:U:d:D:s:S:g         ! even worse

process eej2 = e1, E1 -> j, j
process eej3 = e1, E1 -> j, j, j
process eej4 = e1, E1 -> j, j, j, j
process eej5 = e1, E1 -> j, j, j, j, j

sqrts = 500 GeV
beams = e1, E1

compile

for the four the four jet case eej4, there are 66 processes compiled, about 48 of them should be zero e.g. due to non conserved flavour like in

[12/66] e- e+ -> ubar//1 dbar//2 d/1/ d/2/ ... done. [time: 0.94 secs, total: 1:07 mins, remaining: 54.71 secs]

but all of them use the same amount of time (~1s).
If one takes the 5jet case, every process takes the same time (~6s), regardless of being physical or not, like

[012/270] e- e+ -> ubar//1 ubar//2 u/1/ d/2/ gl// ... done. [time: 5.68 secs, total: 25:54 mins, remaining: 24:45 mins]

I didn't count how many of these processes are unallowed. Including strange quark even worsens this.

So there's no way that O'Mega returns almost immediately.

[sschmidt]

So the eej5 takes like 25 minutes to compile, 9 minutes of those are used for the various e+e- -> ggggg processes.

What is even worse (maybe this needs to be a new ticket):
When processing an input file with processes using aliases the processes are recompiled every time the input file is used. W2 doesn't realize that the processes had been compiled before and could be used again.

[ohl]

Replying to sschmidt:

Replying to ohl:

Replying to sschmidt:

it looks as if Omega compiles e+e- -> gg

That's normal, it just attempts it and returns almost immediately.

So there's no way that O'Mega returns almost immediately.

That's right.

I could add heuristics for processes of only uncolored matter and gluons. Unfortunately, once we add the Hgg and Haa vertices, they are no longer valid. In order to support such optimizations reliably, models will have to offer hints about selection rules.

This has to wait until v2.1.

[Juergen Reuter]

Somehow this has to be improved, at least for the gluons, maybe there could be a vertex check or so, irresp. of the colour flows.

Up to then, one should separate gluons from quark jets to improve performance, although this cannot be the final answer.

[ohl]

This is a separate issue and covered by the new ticket #204.

Closing this ticket. because the original issue has been resolved.

[Juergen Reuter]

Milestone v2.0-rc3 deleted