[Rivet] Rivet - question from newbies (general and J/psi related)

[Andy Buckley]

On 14/06/13 01:39, Hendrik Hoeth wrote:
> Hi Antonin,
> 
> quoting a pdf is kind of awkward, so you'll have to live with numbered
> answers:
> 
> A.1: UnstableFinalState returns all status==1 and status==2 particles,
>      minus duplicates, minus reggeons, minus decaying photons, minus
>      partons, minus zero-momentum particles. So yes, all particles you
>      mentioned will be seen by UnstableFinalState. And no, you can't
>      choose what you get. You get everything. If you want to select, you
>      need to use IdentifiedFinalState or VetoedFinalState.
> 
> A.2: Stable/unstable is set by the generator.
> 
> A.3: See A.1. You get all status==1 and status==2 particles.
> 
> A.4: See A.1. Yes. Mothers, daughters, sisters, the whole family.
> 
> B.1: The two analyses you quote ask very different questions, so
>      recommending one over the other would be like answering the
>      questions whether a VW Beatle or a television is better. If you
>      want to know whether a certain particle appears amongst the
>      ancestors, then ask for that particle (-> ALICE). If you want to
>      know if any B-hadron (and there are plenty!!!) appears amongst the
>      ancestors, then ask for that (-> ATLAS). It depends on your
>      application.
> 
> B.2: Ancestors are ancestors. As opposed to just parents. See
>      http://rivet.hepforge.org/code/hepmc/classHepMC_1_1GenVertex_1_1edge__iterator.html

I agree with all of this. But just a comment that we're aware that
there's lots of room for improvement in how we help analysis authors to
analyse decay chains, largely because the early analyses that drove
Rivet development were coarse things based on jets and high-pT leptons!
But as things like hadron decay measurements and modelling become more
accurate (and LHCb and ALICE get more involved), there's definitely a
need to make decay-analysis easier. Maybe you already have sophisticated
analysis systems for this in the experiment and could give us some
suggestions? We're happy to implement helper code, and even more-so if
it's a design that's already been proven to work!

> C.1: Bins in histograms are automatically normalized for their bin
>      width. In a histogram (as opposed to a bar chart) the defining
>      quantity is the area of the bin, not its height.
> 
> C.2: The weight is supplied by the MC event generator. It might be the
>      same for all events, it might be a different weight for each event
>      (to make the generation more efficient (or possible at all!)). The
>      sumOfWeights() is the sum of weights of all events Rivet has seen.
>      Scaling by 1./sumOfWeights() means normalizing the histogram area
>      (if for example you had exactly one fill per event, the histogram
>      will be normalized to 1).
> 
> C.3: crossSection() is the cross-section value provided by the
>      generator and of course depends on the process. But it doesn't know
>      anything about your analysis. If you want to document your cut
>      flow, you have to do some bookkeeping yourself.
> 
> C.4: Yes, it is up to the user to define what NSD means. Because NSD is
>      not a physically meaningful definition. Cuts are. Triggers are. But
>      "NSD" is not.

Right. So if the events in the analysis come from a selection/veto of
particles in forward/backward trigger detector regions, then it's all
observable and that's what you should implement in the Rivet analysis.
If it depends on post-hoc "corrections" for turning on/off the Pythia SD
processes, then the only way to really reproduce the analysis for MC
comparison is to run Pythia without the SD processes. Obviously we
prefer the former!

> D.1: The Multiplicity projection takes whatever particles you feed into
>      it and counts them for you. If, like in your "cnfs" example, you
>      feed it charged and neutral stable particles within -4 < |eta| < 4
>      and pT>2GeV, then it will count those. If you feed it something
>      else, well, it'll count that.
> 
> D.2: I'm sorry, I don't understand the question.

I'm also confused! A FinalState or ChargedFinalState etc. projection
returns *final state* particles, and that's what's being counted. There
is no detailed treatment of cascade decays, etc., since they are not
final state particles. Actually the Multiplicity projection is not
really necessary except as an example, since it doesn't answer much more
than myfinalstate.size()!

If you want to look for specific decay chains, then using
UnstableFinalState and jump into HepMC-land via the
particle.genParticle() method. This is exactly what we'd like to make
easier for you, and where we're very open to suggestions.

> E.1: Yes. Read the generator manual on setting the random number seeds.
>      About combining the results, well, it depends on your observables.
>      Overall, yodamerge is a good starting point.

Yes. This is all improving. It's hard to get right in general, but we
have a way, and most of the components are already in place.

> E.2: Yes. Read the generator manual.

If you *really* want all production processes then I think you need min
bias. I assume that the analyses you quote are looking for e.g.
sufficiently high-pT charmonia that using the pp->QQ matrix element is
not a terrible approximation. Or their advice is wrong... I hope not.

> E.3: Read the generator manual.

One thing I know is that Pythia6 does not, but Pythia8 now does include
QED FSR in quarkonia decays (from version 8.175 onwards).

> E.4: Read the generator manual and/or visit the MCnet school. All
>      generators come with examples, and all our previous schools used
>      the C++ generators in the tutorials, not the Fortran ones.
> 
> In August there will be the next MCnet school with lectures and several
> hands-on tutorials on Rivet and the major MC event generators. The
> generator authors and the Rivet authors will be present. This might be a
> good opportunity to learn more about Monte Carlo, and probably answers
> all your questions (certainly all the ones you asked in your mail). Note
> that the registration deadline is soon -- if you miss it but still want
> to go, contact the organisers:
> http://www.montecarlonet.org/index.php?p=MCSchool/Gottingen

Yes, recommended!

I just uploaded some slides from the Les Houches workshop of the last
two weeks, which give a tutorial on Rivet 2.0.0b2 using the "sacrifice"
interface to Pythia8. That's just a convenient command-line way to steer
Pythia8: you can just as easily make one of the standard example
programs, but for a tutorial this was a nice way to demonstrate things
without needing to go back to the Fortran gens. Slides are at
http://rivet.hepforge.org/rivet-tutorial-200b2.pdf

Cheers,
Andy

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