$restrictions (-cascade in O'Mega parlance) conflict w/ flavor sums

[dwiesler]

There are two issues with the restrictions to intermediate-states of the matrix element, which are also given in the attached sindarin file:

process prob1a   =   u,U -> T,b,E1,n1 { $restrictions =  "4+5+6~t"}

process prob1b   =   u,U -> T,b,E1,n1 { $restrictions =  "4+5+6~tbar"}

process prob1c   =   u,U -> T,b,E1,n1 { $restrictions =  "4+5+6~t && 5+6~W+"}

process prob2a   =   j,j -> T,b,E1,n1 { $restrictions =  "4+5+6~t && 5+6~W+"}

process prob2b   =   j,j -> T,b,E1,n1 { $restrictions =  "5+6~W+"}

1. Particle and antiparticle intermediate states give the same number of diagrams and thus the same numerical result, whereas one choice should actually be forbidden. This is demonstrated with the attached processes prob1a and prob1b.

2. Flavour sums in the initial state partially brake the ME generation, as the resulting diagrams are shown as forbidden, where as they include actual allowed ones. A comparison of the output of processes prob1c and prob2a yields:

| Calling O'Mega for process 'prob1c'
| command: /Users/dw/tools/tmp/w2o/bin/omega_SM.opt -o prob1c.f90 -target:whizard -target:parameter_module parameters_SM
 -target:module prob1c -target:md5sum 8156F6F33F1B4BAE25BA25C5B9F3B644 -cascade '4+5+6~t && 5+6~W+' -fusion:progress 
 -scatter 'u ubar -> tbar b e+ nue'
[1/2] u/2/ ubar//1 -> tbar//1 b/2/ e+ nue ... allowed. [time: 0.72 secs, total: 1.45 secs, remaining: 0.72 secs]
[2/2] u/1/ ubar//1 -> tbar//2 b/2/ e+ nue ... allowed. [time: 0.76 secs, total: 1.48 secs, remaining: 0.00 secs]
.
.

compared to

| Calling O'Mega for process 'prob2a'
| command: /Users/dw/tools/tmp/w2o/bin/omega_SM.opt -o prob2a.f90 -target:whizard -target:parameter_module parameters_SM
 -target:module prob2a -target:md5sum 7CC4648012ACF4C7F87D1FB21D2CE3B1 -cascade '4+5+6~t && 5+6~W+' -fusion:progress
 -scatter 'u:ubar:gl u:ubar:gl -> tbar b e+ nue'
.
.
[03/10] u/2/ ubar//1 -> e+ nue tbar//1 b/2/ ... forbidden. [time: 0.72 secs, total: 7.35 secs, remaining: 5.15 secs]
[04/10] u/1/ ubar//1 -> e+ nue tbar//2 b/2/ ... forbidden. [time: 0.75 secs, total: 7.40 secs, remaining: 4.44 secs]
.
.

which results in an abort due to a type mismatch:

libtool: compile:  gfort -c -I/Users/dw/tools/tmp/w2o/lib/whizard/mod/models -I/Users/dw/tools/tmp/w2o/include/omega
 -I/Users/dw/tools/tmp/w2o/lib/whizard/mod/whizard-core -I/Users/dw/tools/tmp/w2o/lib/whizard/mod/misc -g -O0 prob2a.f90 
 -fno-common -o .libs/prob2a.o prob2a.f90:196.49:

    amp2 = real (omega_color_sum (flv, hel, amp, table_color_factors))
                                                 1
Error: Type mismatch in argument 'cf' at (1); passed REAL(8) to TYPE(omega_color_factor)
prob2a.f90:190.9:

    cf = table_color_factors
         1
Error: Can't convert REAL(8) to TYPE(omega_color_factor) at (1)
| command: /Users/dw/tools/tmp/w2o/lib/whizard/libtool --mode=compile gfort -c -I/Users/dw/tools/tmp/w2o/lib/whizard/mod/models
 -I/Users/dw/tools/tmp/w2o/include/omega -I/Users/dw/tools/tmp/w2o/lib/whizard/mod/whizard-core
 -I/Users/dw/tools/tmp/w2o/lib/whizard/mod/misc  -g -O0 'prob2a.f90'
| Return code = 256
******************************************************************************
******************************************************************************
*** FATAL ERROR: System command returned with nonzero status code
******************************************************************************
******************************************************************************
| There were no errors and    2 warning(s).
WHIZARD run aborted.

If we however restrict only the leptons in this process to stem from a W, the flavour sum does no harm and all goes through smoothly (see prob2b). I guess this is somehow connected to the colourflow governed by the intermediate state.

Last but not least a small caveat, which may be nasty for the end user in day to day Whizard usage: the particle flavour string used in the restriction syntax is NOT the same as the one recognized in the sindarin file. In the example above using T instead of tbar in proc1b results in a flavor.of.string crash of the ME generation. As this depends on the used model, it should at least be documented somehow (manual?).

[dwiesler]

example sindarin file demonstrating restriction problems

[ohl]

Two quick comments

1. is a design decision: the intermediate states can also be spacelike (just combine initial and final stae particles) and there the separation of particle and anti-particle makes no sense. This will not be fixed, but should be documented.

2. this is a bug and I must fix it.

[ohl]

Fixed the abort in r1957 (was a trivial error).

[ohl]

Found the cause (still thinking about a properly designed fix): in order to avoid the generation of redundant matrix elements, I sort the final states - this destroys the relation between the numbers in the cascades and the final state particles.

[ohl]

re: the flavor string: O'Mega uses unique flavor strings, while WHIZARD has always allowed a liberal combination of O'Mega, Madgraph and ComHEP names. I think that unique names are ultimately more user friendly (b/c they're less confusing), but that's a design decision.

[Juergen Reuter]

I am in principle in favour of unique particle names, BUT: e.g. for the W+ there is the name "W+" which has to appear in quotation marks in SINDARIN files, so that I introduced the alternativ name Wp etc. So for some particles two alternatives concerning the names !?

[Juergen Reuter]

Or WHIZARD does an internal translation into a unique representation???

[ohl]

I've made new ticket for the question of unique particle names: #240.

[ohl]

Partially fixed in r1958: final state particles are only reordered, if flavor sums appear in the final state. Flavor sums in the initial state didn't trigger a reordering anyway.

For the full fix, there are two choices:

• don't remove redundant final states iff $restrinctions are applied
• disallow $restrictions for flavor sums in the final state

any other choice will be too confusing to the user.

Moving this design choice to milestone:v2.0-rc4 with reduced priority.

[ohl]

Or do we want a new unambiguous syntax:

  alias j = u:ubar:d:dbar:s:sbar:c:cbar:gl
  alias l = e+:e-:mu+:mu-:tau+:tau-
  alias nu = nue:nuebar:numu:numubar:nutau:nutaubar
  -scatter "e+ e- -> (W+ -> j j) (W- -> l nu)"

Downsides:

• t-channel doesn't fit
• does it conflict with Whizard's cascades?

[dwiesler]

The workaround to this problem introduced in r1958 seems to slow down things a lot: comparing the process e+,e- -> u,ubar,g,g with r1890 reveals:

| Calling O'Mega for process 'jets4'
| command: /localscratch/dwiesler/tmp/w2me-comp/bin/omega_SM.opt -o jets4.f90 -target:whizard -target:parameter_module parameters_SM -target:module jets4 -target:md5sum 28946D2B88B8A5F4EB025DFF1FFDFDD0 -fusion:progress -scatter 'e- e+ -> u ubar gl gl'
[1/6] e- e+ -> u/1/ ubar//3 gl// gl/3/1 ... done. [time: 0.81 secs, total: 4.87 secs, remaining: 4.06 secs]
[2/6] e- e+ -> u/1/ ubar//2 gl/2/3 gl/3/1 ... done. [time: 0.80 secs, total: 4.82 secs, remaining: 3.22 secs]
[3/6] e- e+ -> u/1/ ubar//2 gl/2/1 gl// ... done. [time: 0.78 secs, total: 4.78 secs, remaining: 2.39 secs]
[4/6] e- e+ -> u/1/ ubar//3 gl/2/1 gl/3/2 ... done. [time: 0.77 secs, total: 4.74 secs, remaining: 1.58 secs]
[5/6] e- e+ -> u/1/ ubar//1 gl/2/3 gl/3/2 ... done. [time: 0.83 secs, total: 4.79 secs, remaining: 0.80 secs]
[6/6] e- e+ -> u/1/ ubar//1 gl// gl// ... done. [time: 0.80 secs, total: 4.79 secs, remaining: 0.00 secs]
all processes done. [total time: 4.79 secs]

compared to the recent trunk version r1958:

| Calling O'Mega for process 'jets4'
| command: /localscratch/dwiesler/tmp/w2ohol/bld/src/omega/bin/omega_MSSM.opt -o jets4.f90 -target:whizard -target:parameter_module parameters_MSSM -target:module jets4 -target:md5sum 62E68C4991DBB95240510EE71508A069 -fusion:progress -scatter 'e- e+ -> u ubar gl gl'
[1/6] e- e+ -> u/1/ ubar//3 gl// gl/3/1 ... allowed. [time: 26.97 secs, total: 2:42 mins, remaining: 2:15 mins]
[2/6] e- e+ -> u/1/ ubar//2 gl/2/3 gl/3/1 ... allowed. [time: 26.59 secs, total: 2:41 mins, remaining: 1:47 mins]
[3/6] e- e+ -> u/1/ ubar//2 gl/2/1 gl// ... allowed. [time: 26.35 secs, total: 2:40 mins, remaining: 1:20 mins]
[4/6] e- e+ -> u/1/ ubar//3 gl/2/1 gl/3/2 ... allowed. [time: 26.25 secs, total: 2:39 mins, remaining: 53.09 secs]
[5/6] e- e+ -> u/1/ ubar//1 gl/2/3 gl/3/2 ... forbidden. [time: 26.18 secs, total: 2:39 mins, remaining: 26.47 secs]
[6/6] e- e+ -> u/1/ ubar//1 gl// gl// ... allowed. [time: 26.22 secs, total: 2:39 mins, remaining: 0.00 secs]
all processes done. [total time: 2:39 mins]

If this part of the solution is still work in progress, please ignore this comment. Otherwise we should probably open a new Ticket?!

[ohl]

Replying to dwiesler:

The workaround to this problem introduced in r1958 seems to slow down things a lot: comparing the process e+,e- -> u,ubar,g,g with r1890 reveals:

Apples and oranges:

command: /localscratch/dwiesler/tmp/w2me-comp/bin/omega_SM.opt

vs.

command: /localscratch/dwiesler/tmp/w2ohol/bld/src/omega/bin/omega_MSSM.opt

Unfortunately, the MSSM is much more complex than the SM ...

[dwiesler]

Replying to ohl:

Apples and oranges:

I just realized it too, sorry for that one!

[ohl]

Fixed in r2000 by merging the branch branches/ohl/omega-development/flavor_sums_vs_cascades.

1) from now on cascades (a.k.a. $restrictions) distinguish particles from antiparticles for timelike intermediate states (THIS IS AN INCOMPATIBLE CHANGE OF THE INTERFACE).

1a) Gaussian and on-shell constraints are ignored for spacelike intermediate states, b/c they make no sense

2) final state particles are only reordered if the reordering does not conflict with the cascade. NB: This can lead to double counting, because the intermediate states are NOT tested for identical particles! E.g.

  -scatter "e+ e- -> j j j j" -cascade "3 + 4 ~ Z && 5 + 6 ~ Z"

yields the final states

      1: e+ e- -> ubar u ubar u
      2: e+ e- -> ubar u dbar d
      3: e+ e- -> dbar d ubar u
      4: e+ e- -> dbar d dbar d

[Juergen Reuter]

Milestone v2.0-rc4 deleted