[Rivet] Gentle reminders...

[Andy Buckley]

Frank Siegert wrote:
> Frank Siegert, Friday 08 May 2009:
>> FastJet's D0ILCone does not seem to respect the pTmin that I pass to
>> the constructor, so using:
>>
>>   FastJets jets(fs, FastJets::D0ILCONE, 0.5, 20.0*GeV);
>>   const JetAlg& jetpro = applyProjection<JetAlg>(event, "Jets");
>>   const Jets jets = jetpro.jetsByPt();
>>
>> also produces jets 10 GeV < pT < 20 GeV, because D0ILCone seems to have
>> a default Et_min_ratio of 0.5 somewhere in the fastjet source code,
>> which the jet_min_Et gets multiplied with.
>> Is this to be expected? If so, we should definitely be aware of it in
>> all D0ILCone analyses (and maybe others?). Workaround for me at the
>> moment, is to specify an explicit pTmin to jetpro.jetsByPt(ptMin).
> 
> With this workaround the z+jets analyses seem to work alright.

Good. Can you check this with Gavin, Matteo & Gregory? 
(fastjet at projects.hepforge.org, and maybe copy the Rivet list in on the 
mail) Would this also be responsible for the factors of 2 that Hendrik 
has reported appearing in Lars' CDF_2005 jet shape analysis?

> I am 
> attaching comparison plots vs. revision 1406, to demonstrate how much of 
> an effect the switch to ZFinder and FastJet 2.4 has had.
> The only unexpected discrepancy is in the kT jet rates in MC_TVT1960_ZJETS 
> (pages 34-42). I would understand a scale factor, because vetoEvent() is 
> used together with sumOfWeights(), but the histograms are not simply 
> scaled.
> Maybe it's related to the problems with jet rates in e+e-, or it has to do 
> with the logarithmic axes. It's not a blocker, but would be nice to 
> understand nonetheless.

Yep. Can you report understanding it as a ticket for 1.2.0?

Andy