Phase space generation fails

[Juergen Reuter]

The example Thomas Faber has sent contains an extension to the MSSM (neutrino sector). Sneutrinos are split into real and imaginary part (they are complex because they are part of a chiral superfield I guess, for they carry lepton number), but this is IMHO not the source of the problem. Phase space generation fails. I started investigating this. The process that fails is nR2 => nR1, b1, b1bar which works through an intermediate Higgs (the Z only couples to real and imaginary part). The corresponding scattering process, nR1 nR2 => b1, b1bar works. It also seems to work if one puts the vertices needed to construct a cascade tree to the very beginning. JRR checked, that the model with its entirety of 2500 vertices is correctly present in the cascade module. According to my findings, the routine cascade_match_triplet doesn't accept the final cascade setup because of a mismatch in the sum of cascades, 1,1,1 for the three cascades. This is < 5, which is the depth of the whole cascade. For a corresponding process in the MSSM, H0 => A0, b1, b1bar everything works, and there the final depth numbers are 1+3+1 = 5.

[Juergen Reuter]

Debug output for failed PHS generation

[Juergen Reuter]

Debug output for working MSSM example

[Juergen Reuter]

SINDARIN file for failing phase space generation

[Juergen Reuter]

SINDARIN for corresponding working MSSM example

[Juergen Reuter]

The tarball of the model generated by SARAH with local modifications to let it work with NAG can be found here

https://whizard.hepforge.org/Internal/wo_model_debug.tar.gz

[kilian]

ok, let's take a look ...

[kilian]

1. The model name in the .sin file of the tarball must be lower case. No big deal.
2. But then I'm stuck here:

   | Reading model file '/home/users/kilian/.whizard/share/whizard/models/seesawib_sarah.mdl'
   Runtime Error: models.f90, line 1477: Subscript 1 of NAME_ARRAY (value 1) is out of range (1:0)
   Program terminated by fatal error
   models.f90, line 1477: Error occurred in MODELS:MODEL_APPEND_FIELD_VARS
   models.f90, line 1060: Called by MODELS:MODEL_READ
   models.f90, line 1594: Called by MODELS:MODEL_LIST_READ_MODEL
   rt_data.f90, line 1651: Called by RT_DATA:RT_DATA_READ_MODEL
   commands.f90, line 954: Called by COMMANDS:CMD_MODEL_COMPILE:PRELOAD_MODEL
   commands.f90, line 933: Called by COMMANDS:CMD_MODEL_COMPILE
   commands.f90, line 5763: Called by COMMANDS:COMMAND_LIST_COMPILE
   whizard.f90, line 353: Called by WHIZARD:WHIZARD_PROCESS_STREAM
   whizard.f90, line 332: Called by WHIZARD:WHIZARD_PROCESS_FILE
   main.f90, line 416: Called by MAIN
   Abgebrochen
   

[Juergen Reuter]

Damn, I really forgot to put all fixes into the tarball, sorry. Please replace in the model file:

particle HADRON_REMNANT 90

particle HADRON_REMNANT_SINGLET 91

particle HADRON_REMNANT_TRIPLET 92
  color 3

particle HADRON_REMNANT_OCTET 93
  color 8

by

particle HADRON_REMNANT 90
  name hr
  tex_name "had_r"
particle HADRON_REMNANT_SINGLET 91
  name hr1
  tex_name "had_r^{(1)}"
particle HADRON_REMNANT_TRIPLET 92
  color 3
  name hr3
  tex_name "had_r^{(3)}"
  anti hr3bar
  tex_anti "had_r^{(\bar 3)}"
particle HADRON_REMNANT_OCTET 93
  color 8
  name hr8
  tex_name "had_r^{(8)}"

The missing tex_name and name tags cause these out of range exception.

[kilian]

For the records, two further bugs w/ workarounds:

1. The .opt is only searched in the whizard installation, not in .whizard as intended (so I edited this in the generated default_lib.makefile
2. Typo in the process name in the .sin (that one of the tarball).

With these changes, the example process eemumus of the provided sin runs through without error.

Is this the expected behavior? Not yet tried fail.sin.

[Juergen Reuter]

Correct, the first one I can confirm, I also experienced this, and it is not intended. The Sindarin file was probably by me. So me to blame.

[kilian]

What about this?

******************************************************************************
*** ERROR: Include file 'WHIZARD.par.SeesawIb_Punkt_16' not found
******************************************************************************

[Juergen Reuter]

original input file (with lots of unnecessary stuff)

[Juergen Reuter]

slimmer version of the same file

[kilian]

Thanks! Now I get this, which I think is now expected:

| Beam data (decay):
|   nR2  (mass = 1.8026841E+02 GeV)
| Phase space: generating configuration ...
| Phase space: ... failed.  Increasing phs_off_shell ...
| Phase space: ... failed.  Increasing phs_off_shell ...
******************************************************************************
******************************************************************************
*** FATAL ERROR: Phase-space: generation failed
******************************************************************************
******************************************************************************
WHIZARD run aborted.

So I'll start debugging from here.

[kilian]

Found the cause of the problem.

This is a feature of the algorithm for determining phase space which in this particular case turns out to be fatal. As it happens, the on-shell intermediate Higgs is not possible, so the cascade generator uses the subleading tree with an off-shell Higgs. Fine. At this time, there is already an identical tree in the database with an off-shell Z. Now, if such a thing happens, the generator drops the new tree, since kinematically (being off-shell) they are indistinguishable. Actually, this was a deliberate decision, because otherwise the number of allowed trees could explode. (Think of SUSY neutralinos in intermediate states.)

Unfortunately, the last candidate (the Higgs) is the only one that can couple to the initial particle, so the tree in the database gets dropped afterwards, and the generator doesn't remember that there was also the Higgs tree. The algorithm isn't that smart :(

Without changing the code or algorithm, a workaround is to make the Higgs appear before the other bosons in the model. Or to add vertices with zero coupling. Or to manually move Higgs vertices before Z vertices (cf. description above!)

With code changes, a possible solution is to introduce another phase space switch that keeps flavor info for massive but non-resonant s-channel particles. It's not clear whether this is a good solution since the PS switches are already confusing for any non-expert (read: for everybody)...

[Juergen Reuter]

Milestone renamed

[kilian]

The current agreement (WHIZARD meeting 11-01-2017): leave this as wontfix temporarily for the current implementation, but look at the problem in the upcoming new implementation by Manuel Utsch.

The existence of this bug (or flaw in the algorithm) should be listed on the known-bugs list, together with the possible workaround(s).

[Juergen Reuter]

Milestone renamed

[Juergen Reuter]

Now that we have the actual implementation by MU, did we check this case with the new algorithm? Still, we should document the flaw in the old algorithm.

[Juergen Reuter]

Manual Utsch explicitly checked that this example works with the fast_wood algorithm. This has been documented in the manual in r8090.