Polarized same-sign WW: wrong polarization assignment for final states with tau leptons

Asked by Prasham Jain

Dear MadGraph5_aMC@NLO Authors,

I’m generating polarized same-sign WW (using MG5 v2.8.1) with the following commands:

import model sm-no_b_mass
define l+ = e+ mu+ ta+
define vl = ve vm vt
define l- = e- mu- ta-
define vl~ = ve~ vm~ vt~
define p = g u c d s u~ c~ d~ s~ b b~
define j = g u c d s u~ c~ d~ s~ b b~
generate p p > w+{X} w+{Y} j j QED=4 QCD=0, w+ > l+ vl @1
add process p p > w-{X} w-{Y} j j QED=4 QCD=0, w- > l- vl~ @1

where {X,Y} is either {0,T} or {T,0}. (I’ll further refer to these 2 cases as 0T sample and T0 sample.)

Since I am using unordered mode [Ref: https://arxiv.org/abs/1912.01725], these 2 samples are expected to be identical.

When validating the sample, I apply these 2 selections: n(W)>1 & Ws decay to opposite flavor leptons. Now, amongst the 3 possible cases (e-mu, mu-tau, e-tau), we observe that the 0T and T0 samples agree only in the e-mu channel. In e-tau and mu-tau channels, the W decaying to tau is observed to have polarization preference. In the 0T sample, the transversely polarized W always decays via tau, W{T}>tau nu, while in the T0 sample, the longitudinally polarized W always decays via tau, W{0}>tau nu. This renders a non-closure between the sums 00+0T+TT, 00+T0+TT, and the unpolarized sample, for the cosTheta distribution. Please find attached link to supporting slides with cosTheta plots: https://cernbox.cern.ch/index.php/s/NImv7t9vo52JC5t

Is there some specific setting that I’m not using, which causes this issue?
I am happy to run further tests you might suggest if that helps.

Thanks in advance!

Cheers,
Prasham

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

Thanks for the notification,

I can indeed see that the code has those line for the tau decay
     CALL IXXXXX(P(0,5),MDL_MTA,NHEL(5),-1*IC(5),W(1,4))
     CALL FFV2P1L_3(W(1,4),W(1,3),GC_100,MDL_MW, FK_MDL_WW,W(1,6))
Which indeed means that the tau is always associated to the longitudinal polarization.
The solution for the moment would be to use more specific syntax;

import model sm-no_b_mass
define l+ = e+ mu+
define vl = ve vm vt
define l- = e- mu-
define vl~ = ve~ vm~ vt~
define p = g u c d s u~ c~ d~ s~ b b~
define j = g u c d s u~ c~ d~ s~ b b~
generate p p > w+{X} w+{Y} j j QED=4 QCD=0, w+ > l+ vl @1
add process p p > w+{X} w+{Y} j j QED=4 QCD=0, w+ > l+ vl, w+ > ta+ vl @1
add process p p > w+{X} w+{Y} j j QED=4 QCD=0, w+ > ta+ vl, w+ > l+ vl @1
add process p p > w+{X} w+{Y} j j QED=4 QCD=0, w+ > ta+ vl @1

Cheers,

Olivier

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#2

Hi,

This patch;
https://bazaar.launchpad.net/~maddevelopers/mg5amcnlo/LTS_dev/revision/347
should also fix the issue without needind a dedicated syntax.

Cheers,

Olivier

Revision history for this message
Prasham Jain (jainprasham33) said :
#3

Dear Olivier,
Thank you for your prompt response.

I generated new samples using the suggested syntax (after adding W-W- processes):

import model sm-no_b_mass
define l+ = e+ mu+
define vl = ve vm vt
define l- = e- mu-
define vl~ = ve~ vm~ vt~
define p = g u c d s u~ c~ d~ s~ b b~
define j = g u c d s u~ c~ d~ s~ b b~
generate p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > l+ vl @1
add process p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > l+ vl, w+ > ta+ vl @1
add process p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > ta+ vl, w+ > l+ vl @1
add process p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > ta+ vl @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > l- vl~ @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > l- vl~, w- > ta- vl~ @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > ta- vl~, w- > l- vl~ @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > ta- vl~ @1

The cross-section and cosTheta distributions remain unchanged.
The comparison of plots generated using old and new syntax can be found here: https://cernbox.cern.ch/index.php/s/N1CN7FEHW6JcOVY

I found the lines you quoted:
CALL IXXXXX(P(0,5),MDL_MTA,NHEL(5),-1*IC(5),W(1,4))
        CALL FFV2P1L_3(W(1,4),W(1,3),GC_100,MDL_MW, FK_MDL_WW,W(1,6))
in the file “SubProcesses/P1_qq_wpTwp0qq_wp_lvl_wp_tapvl/matrix1.f” and saw that they are exactly the same for the new and old syntax (“diff” gives nothing).

I haven’t tried using the patch yet. I’d be glad to know if there are other possible solutions, as this would simplify running the simulation using the ATLAS infrastructure.

Thank you.

Best regards,
Prasham

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#4

Ah indeed I made a mistake in the above syntax, in my test, I was not using the @1 and the default is to have different @X,
while if you force all those to be @1, the wrong optimization will occur.
So the following syntax should b working.

import model sm-no_b_mass
define l+ = e+ mu+
define vl = ve vm vt
define l- = e- mu-
define vl~ = ve~ vm~ vt~
define p = g u c d s u~ c~ d~ s~ b b~
define j = g u c d s u~ c~ d~ s~ b b~
generate p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > l+ vl @1
add process p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > l+ vl, w+ > ta+ vl @1
add process p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > ta+ vl, w+ > l+ vl @2
add process p p > w+{0} w+{T} j j QED=4 QCD=0, w+ > ta+ vl @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > l- vl~ @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > l- vl~, w- > ta- vl~ @1
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > ta- vl~, w- > l- vl~ @2
add process p p > w-{0} w-{T} j j QED=4 QCD=0, w- > ta- vl~ @1
output

Cheers,

Olivier

Revision history for this message
Oleg Kuprash (oleg-kuprash) said :
#5

Dear Olivier,

Thanks a lot for the proposed fixes.
Just to clarify why we use @1 for all subprocesses: we found that when interfacing to Herwig for simulating the parton shower, Herwig was not combining the subprocessing correctly. E.g. for a case with two subprocesses, Herwig was rescaling the weights for each subprocess i (i=1,2) by the ratio (sigma1+sigma2)/sigma_i. Therefore the total cross section (sum of weights) after the parton shower was a factor 2 larger than the cross section provided by MadGraph. The workaround was to assign the same label to all subprocesses, to avoid this rescaling.
This didn't happen in case of Pythia.
This is something that should probably be fixed on Herwig side.

Cheers,
Oleg

Can you help with this problem?

Provide an answer of your own, or ask Prasham Jain for more information if necessary.

To post a message you must log in.