[Rivet] Gentle reminders...

[Lars Sonnenschein]

Hello Frank et al.

The D0 con algo has many parameters.
The ones which might be changed are:

  float cone_radius = 0.5;
  float min_jet_Et = 8.0;
  float split_ratio = 0.5;

In particular the second parameter value changed a couple of years ago 
from 8.0 to 6.0 GeV.

Further parameters which should not be touched:

  //the parameters below have been found to be set to the values given 
below
  //in the original implementation, shouldn't be altered
  float far_ratio=0.5;
  float Et_min_ratio=0.5;
  bool kill_duplicate=true;
  float duplicate_dR=0.005;
  float duplicate_dPT=0.01;
  float search_factor=1.0;
  float pT_min_leading_protojet=0.;
  float pT_min_second_protojet=0.;
  int merge_max=10000;
  float pT_min_nomerge=0.;

They should be the same between the fastjet and the rivet version of the 
D0 RunII cone.

Last year I made some comparisons between the development version of 
fastjet and the rivet implementation of the D0 cone algo on an event 
by event basis the jet pT, eta/y and phi values did coincide!

Please check also that the pT ordering in your analysis is exactly what 
you want and in particular identical between the fastjet and rivet 
implementations when you make comparisons.

	Lars


On Sat, 9 May 2009, 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. 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.
> 
> Frank
> 
> PS: Ignore that some of the axis labels are broken, I've fixed this on 
> trunk later.
> 
> 

-- 

 
______________________________________
Lars Sonnenschein    
______________________________________
Home Institution:
III. Physikalisches Institut A, 26A204
Physikzentrum RWTH Aachen
52056 Aachen
Germany
--------------------------------------
______________________________________
CERN:
PH 32/2C-07
CH-1211 Geneve 23
Switzerland
Tel.:+41(22)767-9875
--------------------------------------
______________________________________
FNAL:
D0, PK151
Mailstop #352
Fermilab, P.O.Box 500
Batavia, IL 60510-500
USA
Tel.: +1(630)840-8740
______________________________________