[Rivet] CDF Run-1 pTZ

[Emily Nurse]

Hi all,

I think that the D0 Run II analyses also corrects for QED radiation,  
in an attempt to present the "true Z pT".
We can double check with Gavin but I think this is the case (ie/ from  
the statement  "We use PHOTOS [15] to simulate the effects of
final state photon radiation.").  I also asked the author of the  
analysis a while ago and I think that's what he said.

I'll bet the Run I analysis did the same but we should check.

So it seems to be a pattern that all the analyses so far have done  
this, so we need to cluster back all the photons that we think Photos  
would have simulated. I can make some plots of dR between the lepton  
and photon in W / Z events and maybe we can decide on the best cut to  
make?

For the future we really need to communicate these concerns with the  
electroweak convenors and authors of any current analyses. We should  
define what we want. For electrons it is probably quite simple:
"pT of e+e- pair where an electron is defined as a dR = X cone of EM  
objects".

For muons its a bit more difficult, we don't cluster any photons in  
the muon momenta measurement, but often MIP and/or isolation cuts are  
made. Do we ask that the experiments to correct for this using some  
QED model or do we attempt to model the cuts in our analyses?

Emily.




On 17 Feb 2009, at 17:51, Andy Buckley wrote:

> Peter Skands wrote:
>> Hi Andy,
>>
>> Yeah, correcting all the way back to generator-Z is not so great, I
>> agree. I also heard the DeltaR=0.2 figure. What I do is actually just
>> plot the pTZ at generator-level now, since the corrections from  
>> outside
>> DeltaR=0.2 amount to finite QED-suppressed contributions, so the main
>> correction is going from unclustered to 0.2 and then the rest of  
>> the way
>> should be very minor.
>
> Right: the 0.2 cone should pick up the log-enhanced region.
>
>> I agree that this cannot be the procedure adopted
>> in Rivet, since you actually have to reproduce the analysis  
>> accurately.
>
> Hrmm, as far as reasonably possible: in practice the MC analysis has  
> to
> approximate so many things which are complex in the experiment that I
> wouldn't be completely averse to using a cone of whatever radius and
> stopping there, as long as the correction is heavily suppressed. Which
> in this case it should be. Anyway, given that Rivet currently does no
> photon clustering, anything that picks up the log-enhanced QED  
> emissions
> is an improvement!
>
>> I would try to see if I could get a reference on those 0.2 from  
>> anyone
>> in D0, and then refer to that. Anyway, so as you can see, I don't  
>> think
>> the 'clever' CDF approach is completely stupid, since the difference
>> between it and D0 should be down by a genuine (non-log-enhanced)
>> alpha_em suppression.
>
> Sure, hence it's nowhere near as odious as the hadronisation unfolding
> (or the D0 mess you mention below!)
>
>> But in all fairness D0 also screwed up, and quite
>> a bit worse in my opinion. They measured the Z in a mass window  
>> from 71
>> to 111 GeV. However, they then *correct* that back to a mass window  
>> from
>> 40 to 200 GeV, for no bloody reason! They fill that entire phase  
>> space
>> region with pure model-dependence. So we can't trust those numbers
>> completely either, they probably represent 90% Tevatron and 10%  
>> Resbos.
>> Why they wanted Resbos to contaminate their measurement when they  
>> could
>> have just left the mass window as it was, I just have no clue.
>
> *sigh* This is new to me.
>
> Is this in the Run II measurement, or Run I? Gavin was enthusiastic  
> that
> we should use the newer one, so we can all give him an earful if it's
> the Resbos-contaminated version! I don't know if the Run I measurement
> is problematic in that way, but I recall the peak binning is badly
> chosen for tuning comparisons.
>
> Andy
>
> -- 
> Dr Andy Buckley
> Institute for Particle Physics Phenomenology
> Durham University
> 0191 3343798 | 0191 3732613 | www.insectnation.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.hepforge.org/lists-archive/rivet/attachments/20090217/d0da4489/attachment.htm