[Rivet] missingEt variable in WFinder constructor

[Andy Buckley]

Hi again,

A quick test showed that vectorEt().mod() was the appropriate variable
to be using. This is usually close to the pT of the neutrino from the W
in single-W events.

I've made the change on the trunk (along with a bunch of other updates
-- it would probably be a good idea to sync the multi-event branch now
to avoid nasty conflicts when it's time to merge it back.) Thanks, Ines!
You get a credit in the ChangeLog ;-)

Andy


On 02/02/15 16:35, Andy Buckley wrote:
> On 02/02/15 15:49, Frank Siegert wrote:
>> Hi Andy,
>>
>> On 2 February 2015 at 16:43, Andy Buckley <andy.buckley at cern.ch> wrote:
>>> Hi Ines,
>>>
>>> This must be a meaning of "simpler version" that I'm not familiar with!
>>> I've attached a real minimal working example ;-) The version you
>>> provided did not compile with the latest version of Rivet, so I guess
>>> you are using an old one: which version?
>>>
>>> Anyway, with my cut-down analysis I can reproduce the problem. I added a
>>> printout line to WFinder.cc and see that the value that we are using as
>>> an ET cut is much larger than the neutrino pT:
>>>
>>> Rivet.Projection.WFinder: DEBUG  W- reconstructed from:
>>>    (599.426; 30.861, -0.00629191, 598.631) 13
>>>  + (114.54; -28.4288, 0.264693, 110.956) -14
>>> Rivet.Projection.WFinder: DEBUG  Scalar ET = 131.66 GeV vs. required =
>>> 20 GeV
>>> Rivet.Analysis.MinimalAnalysis: INFO  pT_nu1 = 28.43 GeV
>>>
>>> This looks like a projection bug to me -- I need to look into the
>>> definition of the MissingMomentum projection that we're using,
>>
>> Thanks for looking into it.
>>
>> Is this an event with only one neutrino where it's obvious that/where
>> something is going wrong?
>>
>>> but
>>> surely missing ET needs to be a vector rather than scalar quantity. This
>>> is even suggested in the code comments:
>>>
>>>     /// @todo Restrict missing momentum eta range? Use vectorET()?
>>>
>>> Frank, should I change this:
>>>
>>>     if (vismom.scalarEt() < _etMiss) {
>>>
>>> to use vectorEt instead?
>>
>> I'm afraid you'll have to ask Andy whether he's happy with such a change ;-)
>> https://rivet.hepforge.org/trac/changeset/e7fba2de73c390c478d94c0c4849bd9cd543d332
> 
> Ha! I'll run a few checks and ask myself ;-)
> 
>> But it sounds fine to me.
> 
> Cool, thanks.
> 
> Ines, this *really* means that you'll want to update to the next Rivet
> version! Which should probably happen fairly soon.
> 
> Andy
> 


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