[Rivet] Partonic top support?

[Ben Waugh]

Hi All,

As an experimentalist and sysadmin: adding technical barriers is not the 
best way to discourage dangerous behaviour because (a) the technical 
ability to compile Rivet with additional libraries is not necessarily 
strongly correlated with the wisdom to use this feature wisely, and (b) 
someone, perhaps with a good use case, will end up compiling this in a 
shared area (since we try to avoid duplicating effort where we can) and 
then others will be able to use it without further thought.

On the other hand, keeping analyses that rely on HepMC information 
separate from real experimental analyses, and requiring some additional 
*run-time* configuration to use them seems perfectly reasonable.

Cheers
Ben

On 20/06/16 21:55, David Bjergaard wrote:
> 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.
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>

-- 
Dr Ben Waugh                                   Tel. +44 (0)20 7679 7223
Computing and IT Manager                       Internal: 37223
Dept of Physics and Astronomy
University College London
London WC1E 6BT