[Rivet] Question about WFinder

[Andy Buckley]

Hi Giulio,

This is a good idea. I'm putting together something similar to this, and
will add the multiple eta ranges to the identified and charged final
state projections. Just to check, I think it makes sense to have no eta
cuts on the neutrino either: right?

Andy


On 25/02/10 17:15, Piergiulio Lenzi wrote:
> Hi Andy,
>    thanks for your answer,
> I actually found a trick to do the job (well something still has to be
> refined).
> The idea is to run the InvMassFinalState on a MergedFinalState produced
> out of two IdentifiedFinalState's, one with all the charged leptons,
> with pt and eta cuts, and one with all the neutrinos.
> The only problem is that IdentifiedFinalState doesn't take a vector of
> eta ranges, but I think this is easily fixable.
> I'm attaching a patch file that I produced on top of 1.2.0b. I hope this
> is a good starting point .
> Thanks!
> Giulio
> 
> 
> 
> Andy Buckley wrote:
>> On 24/02/10 17:37, Piergiulio Lenzi wrote:
>>  
>>> Dear Rivet developers,
>>>     I'm trying to use the WFinder projection, and I noticed that the
>>> pt cut and eta  range are actually applied both to the charged lepton
>>> and the neutrino. Can you confirm this?
>>> I'm not sure whether this is the expected behavior or not, especially
>>> the eta cut on the neutrino is not something that one can apply in an
>>> experiment. If I had to choose, I would prefer not to check the
>>> neutrino eta and pt at all when building the W candidate, and then
>>> reproduce the experiment MET cut with a cut on TotalVisibleMomentum.
>>> What do you think about that?
>>>     
>>
>> Hi Giulio,
>>
>> I completely agree. I wrote the WFinder as a partial clone of the
>> ZFinder, really only modified to make sure that photons aren't clustered
>> in a cone around the neutrino. It would make sense to also take this
>> more realistic approach to MET and lepton pT cuts for W reconstruction.
>>
>> I was hoping that I could make this fix quickly, but the
>> InvMassFinalState projection takes a single FinalState projection as a
>> constructor argument so it's not immediately easy to make the change.
>> I'll see if I can neatly enhance the InvMassFinalState to be able to be
>> directly supplied with particles, which seems the easiest approach: I'm
>> not immediately sure if this will screw up the caching system. Any other
>> ideas, e.g. from Frank?
>>
>> Andy
>>
>>   


-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh