#331 closed defect (fixed)
WZ+1j MC@NLO weight problems
| Reported by: | Frank Siegert | Owned by: | support@sherpa-mc.de |
|---|---|---|---|
| Priority: | major | Milestone: | rel-2.2.0 |
| Component: | Unknown | Version: | 2.1.1 |
| Keywords: | Cc: |
Description
When generating lllv+1j with MC@NLO the corresponding weight from the CS_MCatNLO reweighting (subtraction vs. shower kernels) is not well-behaved:
CS_MCatNLO::GeneratePoint(): Weight is 89387.7. Retry with charge factor 10. CS_MCatNLO::GeneratePoint(): Weight is -1.3673e+06. Retry with charge factor 10. CS_MCatNLO::GeneratePoint(): Weight is 69584.8. Retry with charge factor 10. CS_MCatNLO::GeneratePoint(): Weight is -2521.67. Retry with charge factor 10.
The attached run card allows to reproduce this right away during event generation (library writeout takes ~25 minutes, integration ~10 minutes). Is this an inherent problem in using spin-correlated subtraction terms vs. a spin-averaged shower or simply a bug? In both cases, any ideas for a solution? The current workaround would be to use only MENLOPS for this type of sample as the 0j process seems to be fine. Interestingly, this problem does not appear in llll or llvv production.
Attachments (2)
Change History (8)
Changed 10 years ago by
comment:1 Changed 10 years ago by
comment:3 Changed 10 years ago by
Unfortunately, also the mapping fixes in r25186 do not fix this issue.
comment:4 Changed 10 years ago by
This is still present in the current trunk (r25784), I am attaching an updated run card with the new Order setting and with stable WZ for simplicity.
comment:5 Changed 9 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
It looks like this has been fixed by the recent AMEGIC changes on trunk!
I can't be completely sure, because I can't run high statistics yet due to a new crash (cf. bug #359), but from all I can see these MC@NLO weight warnings do not appear anymore.
I am also attaching an updated run card where the widths of W/Z are set to zero, so that there are no gauge warnings during the library checks.
comment:6 Changed 9 years ago by
Just for completeness: As a workaround in 2.2.0 it seems possible to use AMEGIC_CUT_MASSIVE_VECTOR_PROPAGATORS=0 to get around these problems, at least no more warnings appear.
This also happens for onshell WZ production, completely independent of the decay mode.