[Rivet] Partonic top support?

[David Bjergaard]

Hi,

As an experimentalist: If you can't measure it with the detector, it shouldn't
be easily accessible. I vote for: If you don't play by the rules, you don't get
an official analysis designation.  I think the rules should stand as they are.

That being said, there are times when accessing the truth information for
feasibility studies is useful, and not having tools for accessing the HepMC
directly is a real pain.  

Could you support a compromise: Provide a HepMC hooks, but do not compile them
by default.  If a user tries to use them, Rivet barfs with undefined reference
errors and the user has to recompile rivet with the HepMC helper library.

This makes it possible, provides a uniform API, but makes the barrier for use
high enough that people have to think hard before they use it.  Also, it
automatically enforces the current rules.  If someone submits an analysis that
relies on the HepMC API, it shouldn't compile with a vanilla rivet install.

Your PS is a separate issue entirely, but since its fair game: Move everything
to a github organization, and make the analyses a separate library(ies).  You
can build them and install them alongside rivet.  Any rivet analysis that is in
the official github organization is blessed as canon, any one that isn't can do
whatever they want. You could even make the analyses a la cart, and it wouldn't
take a year to re-link every analysis ever blessed when you make a small change
to the core of rivet!

    David

Andy Buckley <andy.buckley at cern.ch> writes:

> Hi all,
>
> As we all know, we *massively* favour writing Rivet analyses based on
> post-hadronisation particles. And that approach has had increasing
> purchase in the experiments, with the likes of fiducial "pseudo-top"
> measurements increasing.
>
> But for top analyses in particular, there are many useful analyses
> that rely on parton-level tops. For example, we were sent a CMS
> analysis a few months ago which included a parton-top finder digging
> around in HepMC... and I've not included it in the official analysis
> collection because it doesn't fit with our philosophy. I don't need to
> repeat the many reasons that this approach is suboptimal, but the
> measurements will continue to be made, there is still useful physics
> in them, and it seems unfortunate for Rivet to not be able to include
> them.
>
> I wonder if this situation is sufficiently nuanced that we should
> swallow our distaste and provide an official "DodgyPartonFinder" to
> avoid repetition of that fragile code? I'd want to make it print out
> some warning messages to flag up the dangerous unportability, and
> clearly mark as dangerous in the .info file of any analysis that uses
> it... but it's still better than needing to maintain n *different*
> implementations of dirty HepMC-walking parton finder algorithms.
>
> I'm convinceable either way, but (as having initiated this thread
> suggests) I'm leaning toward thinking that analysis coverage and
> pragmatism are sufficiently valuable to allow a compromise... in the
> case of top physics.
>
> Thoughts & feelings? I expect controversy -- please deliver ;-)
>
> Andy
>
> PS. As Rivet v3 approaches we also need to develop a plan for how
> future analysis distribution, separated from the core library, can
> work without destroying the quality control that we've made a key
> feature. Maybe we'll grasp that nettle in person in September, but I
> just note here that we could have several "grades" of approval, and
> hence put partonic top top analyses in a "use with caution" category.