corrupt assignment of parameter values beginning from r3104

[fbach]

I observe a corrupt assignment of model parameter values set in the sin file. For illustration, see foo.sin with examples in the SM_top_anom model attached (although I didn't find an ordinary SM process with this buggy behaviour, this seems to be independent of the model code, because it occurs precisely with r3104 where the new version of openmp was merged): when I set the coupling vr_tbW_Re to 0 (more specifically, < 10^-7) once in the sin file, all subsequent non-zero coupling assignments in the Whizard run appear to have no more effect on the integration result. However, Whizard still "sees" these assignments somehow, because the integration result does change with very high coupling values such as > 10⁶. This happens only in a restricted subset of processes (under "FAILS" in the file), while everything is perfectly fine in other, similar ones ("WORKS").

[Christian Speckner]

Very weird. I'm looking at it right now, but it will some time to find out what actually happens. Have you checked whether the problem persists when you disable OpenMP or don't enable it in the first place (at configuration time)?

[fbach]

Sorry, I forgot to mention that... OpenMP's disabled by default and I never enabled it manually.

[Christian Speckner]

Jep, just found out myself that OpenMP has no influence. This makes it doubtful that the changes in O'Mega triggered the problem as the code it generates is unchanged if -target:openmp is left out. The other changes are also mostly trivial, and I see nothing what could affect passing the parameters. Valgrind doesn't see anything either. I'll try to identify the cause, but it might take a while.

[Juergen Reuter]

Guys, I demystified this a little bit: it is the numerical helicity selection which is going berserk. FB, if you include ?helicity_selection_active = false in the SINDARIN file the r3104 works the same way as the r3103. WHIZARD does not "forget" about the parameter of the coupling constant, but it seems to switch off certain helicity combinations at some point. CS has reordered the arguments of the amplitudes (exchange color <-> helicity) for better ordering in cache, and had to rewrite the routines for the helicity selection rules. It seems that something has gone wrong or at least weird here. CS, I hope that this helps you to fix this!

[Christian Speckner]

Thanks Juergen, brilliant guess, you saved me a lot of debugging. When implementing OpenMP, I introduced a list of all active helicities in order to get rid of empty loop iterations and thus optimize the loop scheduling. However, reset_helicity_selection did not properly reset this list. In Fabians model, setting parameters to zero can eliminate helicity combinations which are never reenabled even if the parameter is changed again. Fixed in r3660, sorry for the inconvenience.