[Rivet] WFinder has a problem with purely partonic events

[Andy Buckley]

Hi Holger,

I don't really understand -- why is this not an appropriate method in 
partonic events?

Here you have a back-to back 2-body event, where both the neutrino and 
electron are heading off down the beam-pipe. There's no PDF beamline 
boost / beam remnant modelling at this stage, I guess?

In that case a) you are not looking at a realistic collider event, so be 
careful, b) you'd better not look at anything related to raw eta/y/z, 
including detector acceptance cuts. But the MET value is correct at 
around 27 GeV. Where's the mistake?

It's useful that Rivet can largely be run on partonic events, and we 
should strive to keep it that way. But that requires the inputs to be 
suitable, i.e. kinematic frame, HepMC-compatible status codes, standard 
PIDs, etc.  I think the missing momentum projection is actually ok: IIRC 
it makes its decisions about what interacts based on the general charge 
properties of that particle species, so quarks and gluons should be 
classed as as interacting as the hadrons that they turn into.

This is a good way to do things --- it's correct up to the accuracy of 
the simulation. We should *really* resist the temptation to build in 
special behaviours for parton events, and *really*, **really** avoid 
flaky "parton mode detection mechanisms" like assuming things about the 
beam representation. Building an event with hadron beams and partonic 
final-state is not obviously insane, and special behaviours make 
everything more complex and fragile.

Is there really a problem here?

Andy



On 20/05/16 17:48, Holger Schulz wrote:
> Hi,
>
> the WFinder or more precisely the MissingMomentum it is based on
> has a problem when running on purely partonic events:
>
>
> EventScale -1 [energy]      alphaQCD=0.120687  alphaQED=0.00776384
> PdfInfo: id1=2 id2=-1 x1=0.000319351 x2=0.303109 q=78.7088 xpdf1=2.25358
> xpdf2=0.00657298
>
>                                         GenParticle Legend
>         Barcode   PDG ID Name            Stat  ProdVtx DecayVtx
> (       Px,       Py,       Pz,       E ,        m)
>       10001        2 u                  3       -2       -1 (
> +0,       +0,    +1.28,    +1.28,-6.12e-07)
>       10002       -1 d~                 3       -2       -1 (
> +0,       +0,-1.21e+03,+1.21e+03,        0)
>       10003      -11 e+                 3       -1       -2 (
> +19.7,    -19.1,     -171,     +173,-1.91e-06)
>       10004       12 nu_e               3       -1       -2 (
> -19.7,    +19.1,-1.04e+03,+1.04e+03,-1.53e-05)
>       10005        2 u                 11        0       -2 (
> +0,       +0,    +1.28,    +1.28,-6.12e-07)
>       10006       -1 d~                11        0       -2 (
> +0,       +0,-1.21e+03,+1.21e+03,        0)
>       10007      -11 e+                 1       -2        0 ( *+19.7,
> -19.1,     -171,     +173,-1.91e-06*)
>       10008       12 nu_e               1       -2        0 ( *-19.7,
> +19.1,-1.04e+03,+1.04e+03,-1.53e-05*)
>
> Rivet.Projection.WFinder: TRACE  MET = 27.452 GeV vs. required = 25 GeV
> Rivet.Projection.WFinder: DEBUG  Found at least one dressed lepton:
> *(172.942;  19.6765,-19.1428, -170.749) *
> Rivet.Projection.WFinder: DEBUG  Found missing 4-momentum: *(172.942;
> -19.6765, 19.1428,  170.749)*
>
> This is the 'culprit' if you want to call it a culprit:
>
>     const FourMomentum missingMomentum(double mass=0*GeV) const { return
>     visibleMomentum(mass).reverse(); }
>
> That's probably not the best choice for partonic events.
>
> I would suggest we check in the WFinder is the beams
> are defined. If they aren't we can probably safely assume that
> this is a partonic event where you would reconstruct the
> W from the neutrino anyways and hence use the old method
> of reconstructing the W from the neutrino.
>
> Here is a plot (thanks Marek) that illustrates the current situation:
>
>     http://www.physik.uzh.ch/~marek/plots/YFS/Wtest/MC_WINC/W_mass.pdf
>
> red is purely partonic
> blue is with parton shower
> green is with parton shower and beams
>
> I.e. the WFinder result depends on whether you have particles
> travelling down the beam pipe or not.
>
> Not sure whether this is related to the problem Raghav reported.
>
> Cheers,
> Holger
>
>
>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow