changing the number of calls in integrate affects helicity selection heuristics

[sschmidt]

Integrating the two processes

process W1 = u, D -> E1, n1
process W2 = D, u -> E1, n1

the Contributing Helicity Combinations for the process W2 are

| Contributing Helicity Combinations:     2 of    16
| Threshold: amp / avg >  0.22E-05 =  0.10E+11 * epsilon()
|    1:    1  -1  -1  -1
|    2:    1  -1   1  -1

in case the number of calls is less than 40000 and

| Contributing Helicity Combinations:     3 of    16
| Threshold: amp / avg >  0.22E-05 =  0.10E+11 * epsilon()
|    1:    1  -1  -1  -1
|    2:    1  -1   1  -1
|    3:    1  -1   1   1

otherwise.

1) The right-handed neutrino in the third combination shouldn't be there, or am I wrong?

2) The number of combinations shouldn't depend on the number of calls, but this was reproducable. Changing the number of iterations has no effect on this though.

Tested with r1671 with both nagfor and gfortran. See the attached file for an example input file.

[sschmidt]

probably related to #40

[ohl]

I agree that right handed neutrinos should not show up here. However Whizard and O'Mega currently don't know that in the standard model only left handed neutrinos couple. What you see is numerical noise in the vertices and wave functions.

But why does this change from 39999 to 40000 calls? That's subtle. It's not the 40000th call (at this time the helicity mask is frozen), but Whizard uses a different stratified sampling sequence, which changes the first calls, during which the helicity mask is adapted.

You can see this from the example

process W2 = D, u -> E1, n1
compile
sqrts = 1000
beams = p, p -> lhapdf
?helicity_selection_active = false
seed = 0
integrate(W2) { iterations = 1:39998 }
seed = 0
integrate(W2) { iterations = 1:39999 }
seed = 0
integrate(W2) { iterations = 1:40000 }
seed = 0
integrate(W2) { iterations = 1:40001 }

where the integral doesn't change from 39998 to 39999 and from 40000 to 40001, but noticably from 39999 to 40000.

The right handed neutrino goes away, if you increase the threshold (dangerous) and it depends on the seed.

This will be fixed when I implement analytic helicity selection rules, but is not really avoidable with the numerical heuristics.

I leave the ticket open (in final rather that rc2), because the behaviour should be mentioned in the documentation.

[sschmidt]

And once again, I learned something new :-)

[Juergen Reuter]

Am I right that this ticket is only crying for some documentation in the manual? ThO, can you provide me with a text schnipsel of explanation? Then I can include this in the manual.

[ohl]

It's not a bug, but a feature.

[Juergen Reuter]

Milestone v2.0.0final deleted