sherpa is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (/hepforge/svn/sherpa does not appear to be a Subversion repository.). Look in the Trac log for more information.
Modify

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

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

Run.dat (507 bytes) - added by Frank Siegert 9 years ago.
Run.2.dat (530 bytes) - added by Frank Siegert 8 years ago.
new run card for recent trunk

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by Frank Siegert

Attachment: Run.dat added

comment:1 Changed 9 years ago by Frank Siegert

This also happens for onshell WZ production, completely independent of the decay mode.

comment:2 Changed 9 years ago by Frank Siegert

This is reproducible with trunk r25184.

comment:3 Changed 9 years ago by Frank Siegert

Unfortunately, also the mapping fixes in r25186 do not fix this issue.

comment:4 Changed 9 years ago by Frank Siegert

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 8 years ago by Frank Siegert

Resolution: fixed
Status: newclosed

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.

Changed 8 years ago by Frank Siegert

Attachment: Run.2.dat added

new run card for recent trunk

comment:6 Changed 8 years ago by Frank Siegert

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.

Modify Ticket

Change Properties
Action
as closed The owner will remain support@sherpa-mc.de.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.