Make forbidden processes non-fatal

[sschmidt]

When replacing the Z in decays.sin with a Higgs, W2 fails in compiling and gives errors due to missing table_color_flows and table_ghost_flows:

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 -lgfortran hee.f90  -fPIC -o .libs/hee.o
hee.f90:62.21:

    table_color_flows
                     1
Error: PARAMETER at (1) is missing an initializer
hee.f90:63.77:

logical, dimension(n_prt, n_cflow), parameter, private :: table_ghost_flags
                                                                           1
Error: PARAMETER at (1) is missing an initializer
hee.f90:132.25:

    a = table_color_flows
                         1
Error: Symbol 'table_color_flows' at (1) has no IMPLICIT type

[sschmidt]

example sin file

[sschmidt]

Seems very strange: Having only

process hh = e1, E1 -> H, n1, N1

(removing the Higgs decays) works, with the decays

process hee =   H -> e1, E1
process huu =   H -> u, U

process hh = e1, E1 -> H, n1, N1

produces the aforementioned error. The different process

process eeHH = e1, E1 -> H, H

also don't work. and gives the same error, while

process eeZZ = e1, E1 -> Z, Z

works.

[kilian]

I recall that H -> u, U and H -> e+ e- are both zero, arent' they?

[sschmidt]

Sorry, I overestimated the numerical skills of W2 (I knew they were small...). Nevertheless, an error about color-flow in an e+ e- -> H -> e+ e- seems quite strange to me...

[sschmidt]

Damn Freudian slips ;-)

BTW: Is H-> e+e- zero because of the numerics ore because the Yukawa coupling was set to zero (as an approximation)?

After replacing the electrons by muons, the input file works, so removing the bug would be only in order to make the program foolproof. (for people like me :-) )

[Juergen Reuter]

Higgs couplings are there only for t, b, tau. For the muon because of only one single special application.

[Juergen Reuter]

When a process is forbidden, then WHIZARD does not issue a message, but just crashes in compilation! A very user-unfriendly behavior.

[Juergen Reuter]

This is a very confusing one for the user. Now I introduced an O'Mega emergency stopp, if there are no processes. But WHIZARD does not know how to handle this yet.

[Christian Speckner]

I've taken a look into passing this condition to WHIZARD via the exit status of the O'Mega process. This is viable but, however, the exit status as returned by "os_system_call" is useless as "system" encodes the exit code in a supposedly platform specific way (at least subject to endianess issues, possibly more). POSIX defines a portable way of converting it in sys/wait.h but, unfortunately, this is implemented as a macro, so it can't be directly used from FORTRAN. Therefore, I see three ways to accomplish this:

• 1) Capture and parse the STDOUT / STDERR output of O'Mega.
• 2) Write a small piece of C which provides a conversion call.
• 3) Determine the actual exit code returned by "system" during configure.

I'm opting and volunteering to implement 2) or 3) if the WHIZARD masters are fine with one of those two :)

[Christian Speckner]

OK, I took the liberty of implementing 2) :) The absence of diagrams is now passed to WHIZARD via the O'Mega exit code, and WHIZARD then bails out with a fatal error. It might be nice to handle this in a more sophisticated way be setting the matrix element to zero at some point in the future, so I am making this a (low priority) feature request.

[Christian Speckner]

Should add that this was done in r1674 ;)

[Juergen Reuter]

This works also for the MAC. Thx CS.

[kilian]

Considering this in conjunction with #178 (jet summation), I'd rather think the best solution is that O'Mega generates a valid interface where number_flavor_states is zero, and Whizard checks for this. This doesn't need an exit code, and we are free to just issue a warning and continue. Just make sure that transferring (unused) zero-size tables is no compilation problem.

I revert this to a RC2 ticket.

[ohl]

In the jets branch, O'Mega generates a compilable module, also zero allowd processes. This makes the exit code obsolete. Sorry Christian:(.

[Juergen Reuter]

This seems to be the corresponding error message:

| Integrating process 'eeem'
*** Fatal error: Process 'eeem': beam/process mismatch (collision/decay)

Is this what you want(ed)?

If so, we could close the ticket I guess.

[Juergen Reuter]

Nope we can't. Now I get a seg fault for the input file:

process eeem  = e1,E1 -> e1, E2

compile

sqrts = 500

cuts = all E > 100 GeV [e2:E2]

integrate(eeem)

[Juergen Reuter]

Here is the backtrace of the seg fault:

Program received signal SIGSEGV, Segmentation fault.
0x58467a0f in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0x58467a0f in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x584699ef in malloc () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e45842 in __state_matrices_MOD_node_append_child () at state_matrices.f90:201
#3  0xb7e45a9a in node_make_branch.4532 () at state_matrices.f90:514
#4  0x088cb5b8 in ?? ()
#5  0xbf18618c in ?? ()
#6  0x083f2e84 in ?? ()
#7  0x00000000 in ?? ()

I'll look into it.

[sschmidt]

Replying to jr_reuter:

You get the segfault because the beams statement is missing. If you include it you get the aforementioned error message. So maybe the integration should check if there are beams at all?

[kilian]

Finally done in r1801. Forbidden processes go through smoothly, with appropriate warnings.

[Juergen Reuter]

Milestone v2.0-rc3 deleted