#17 closed task (fixed)
W2 wrong results for massive beams
Reported by: | Juergen Reuter | Owned by: | jr_reuter, kilian |
---|---|---|---|
Priority: | P3 | Milestone: | |
Component: | core | Version: | 2.0.0alpha |
Severity: | normal | Keywords: | ordering of input statements |
Cc: |
Description
W2 seems to be giving wrong results for massive fermionic beams. Massive vector bosons in the initial state seem to be OK, but should be properly tested.
Change History (6)
comment:1 Changed 15 years ago by
Priority: | P4 → P5 |
---|---|
Summary: | W2 wrong results for massive fermionic beams → W2 wrong results for massive beams |
comment:2 Changed 15 years ago by
It looks like that the predefined mass (from MODEL.mdl) is not overwritten by the user-defined value, either in the beam setup or the phase-space integration. For the flux factor, the newest value of the mass is, however, used. When setting a matrix element to a constant, the result coincides with W1 (mass cancels out?), and when setting to the predefined mass in MODEL.mdl, W1 and W2 also agree. For other values there is disagreement. Checking the appearance of mass everywhere now.
comment:3 Changed 15 years ago by
Keywords: | ordering of input statements added; wrong code removed |
---|---|
Priority: | P5 → P3 |
Severity: | critical → normal |
Type: | defect → task |
It's not a bug, it's a feature: in fact, the mass of the incoming was set _after_ the beam statements, which was responsible for the fact that for the masses of the incoming (beam) particles the predefined values have been taken. Although this is a correct parsing order, it might (and will) generate some confusion in the future. To be discussed how to ameliorate this topic. Therefore: defect -> task
comment:4 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:5 Changed 15 years ago by
Milestone: | v2-public → v2.0-beta |
---|
Wolfgang, in case you are faster than I am: the problem comes from the fact that the masses are taken from the original mdl-file (i.e. the default values), and are never overwritten by the user-defined values!!! We already had this problem somewhere else, we have to make sure that this is really caught in all cases.