whizard is hosted by Hepforge, IPPP Durham

Opened 8 years ago

Closed 6 years ago

#797 closed defect (fixed)

Phase space generation fails

Reported by: Juergen Reuter Owned by: kilian, utsch
Priority: P2 Milestone: v2.6.2
Component: phase_space Version: 2.3.0
Severity: normal Keywords:
Cc: thomas.faber.90@…

Description

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.

Attachments (6)

fail_phs.txt (80.4 KB) - added by Juergen Reuter 8 years ago.
Debug output for failed PHS generation
mssm_works.txt (171.2 KB) - added by Juergen Reuter 8 years ago.
Debug output for working MSSM example
fail.sin (566 bytes) - added by Juergen Reuter 8 years ago.
SINDARIN file for failing phase space generation
mssm.sin (229 bytes) - added by Juergen Reuter 8 years ago.
SINDARIN for corresponding working MSSM example
WHIZARD.par.SeesawIb_Punkt_16.orig (31.5 KB) - added by Juergen Reuter 8 years ago.
original input file (with lots of unnecessary stuff)
WHIZARD.par.SeesawIb_Punkt_16 (4.7 KB) - added by Juergen Reuter 8 years ago.
slimmer version of the same file

Download all attachments as: .zip

Change History (25)

comment:1 Changed 8 years ago by Juergen Reuter

Component: corephase_space
Milestone: v2.3.1v2.3.2

Changed 8 years ago by Juergen Reuter

Attachment: fail_phs.txt added

Debug output for failed PHS generation

Changed 8 years ago by Juergen Reuter

Attachment: mssm_works.txt added

Debug output for working MSSM example

Changed 8 years ago by Juergen Reuter

Attachment: fail.sin added

SINDARIN file for failing phase space generation

Changed 8 years ago by Juergen Reuter

Attachment: mssm.sin added

SINDARIN for corresponding working MSSM example

comment:2 Changed 8 years ago by 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

comment:3 Changed 8 years ago by Juergen Reuter

Priority: P1P0
Severity: majorcritical

comment:4 Changed 8 years ago by kilian

Status: newassigned

ok, let's take a look ...

comment:5 Changed 8 years ago by 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
    

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by 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.

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by kilian

What about this?

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

Changed 8 years ago by Juergen Reuter

original input file (with lots of unnecessary stuff)

Changed 8 years ago by Juergen Reuter

slimmer version of the same file

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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)...

comment:12 Changed 7 years ago by Juergen Reuter

Milestone: v2.3.2v2.4.0

Milestone renamed

comment:13 Changed 7 years ago by Juergen Reuter

Milestone: v2.4.0v2.4.1

comment:14 Changed 7 years ago by kilian

Milestone: v2.4.1v2.5.0
Owner: changed from kilian to kilian, utsch
Priority: P0P2
Severity: criticalnormal
Status: assignednew

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).

comment:15 Changed 7 years ago by Juergen Reuter

Milestone: v2.5.0v2.6.0

Milestone renamed

comment:16 Changed 7 years ago by Juergen Reuter

Milestone: v2.6.0v2.6.1

comment:17 Changed 6 years ago by 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.

comment:18 Changed 6 years ago by Juergen Reuter

Milestone: v2.6.1v2.6.2

comment:19 Changed 6 years ago by Juergen Reuter

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.