[Rivet] Upcoming paper, and rivet routines from CMS SMP-12-019 (jet mass measurement in dijet and V+jet events)

[Andy Buckley]

Indeed, we can maintain the code in either form, but I think it is a CMS
decision on whether or not it is more usable (i.e. will be used!) if
split apart. For example, merging of histograms may be harder to
organise if e.g. the dijet plots are all empty (or worse, incorrectly
filled) when running with V+jets, and vice versa.

Just to keep things simple, and to avoid you having to put in e.g. a Z
veto for the dijets just to avoid filling plots incorrectly -- there is
no 100% robust way to determine the process type from an event record --
my bias is toward splitting into two analyses. But I've not seen the code.

I think if written as one analysis it would most likely always have to
be run as if it was two separate ones, maybe with awkward technicalities
needed to avoid the accidental overlaps. Since the dijet/V
cross-sections are so different, you're never going to run a generator
on both process types at the same time. In fact, it's pretty much
exactly the same pair of processes as were split into two analyses for
CDF's underlying event paper, and that has worked well. My $0.02.

Andy


On 23/09/13 09:04, Hendrik Hoeth wrote:
> Hi Sal,
> 
> really: either is fine.
> 
> Hendrik
> 
> Thus spake Salvatore Rappoccio (rappoccio at gmail.com):
> 
>> Hi, Folks,
>>
>> Coming back to this : what's the ultimate decision here? We really
>> need something without delay. One routine, or two? Yes, there's no
>> fundamental objections either way, but if no one will use it if it is
>> in one routine, then we're going through a bit of a colossal effort
>> for very small payoff, which no one wants to see, of course.
>>
>>
>> Cheers,
>> Sal
>>
>>
>> On Sat, Sep 7, 2013 at 12:10 PM, Andy Buckley <andy.buckley at cern.ch> wrote:
>>> Hi Albert,
>>>
>>> Sorry for the delayed reply -- I was on holiday after Boost and catching
>>> up with work while wading through 3000 emails has taken some time!
>>>
>>> I think the decision on whether we can accept it depends on how
>>> maintainable and portable the implementation is: if the decision on
>>> which histograms to fill is made by looking inside the HepMC record
>>> internals to classify a "hard process" then I would *really* prefer that
>>> it be split, since avoiding such features is precisely what Rivet is
>>> designed to avoid/discourage! (And we would then be responsible for
>>> maintaining/fixing it when that check doesn't work for some new
>>> generator in the future.)
>>>
>>> But if the behaviour is much safer than that, then it should be fine...
>>> it's your call, but if you can show me a bit of example code or describe
>>> how it currently works then I'll let you know.
>>>
>>> Typically the useful form of measurement data is corrected back to
>>> particle level to allow comparison to particular classes of hard event
>>> type, so for e.g. the CDF combined jet/Drell-Yan UE measurement it made
>>> most sense to split the analysis into two, one for each kind of matrix
>>> element -- obviously it wouldn't make sense to mix QCD and DY matrix
>>> elements in a generator run: you'd never get any events from the latter!
>>> But I don't know exactly what situation you are trying to handle.
>>>
>>> Sorry to not give a definite answer from the available info: there's no
>>> *fundamental* objection either way, but we will need to maintain the
>>> code ~forever and it does need to be *usable*, otherwise what's the point?!
>>>
>>> Best wishes,
>>> Andy
>>>
>>>
>>> On 21/08/13 09:23, Albert Knutsson wrote:
>>>>
>>>> Hi Andy,
>>>>
>>>> I think it is great that you accept more than one plugin/paper.
>>>>
>>>> Previously I was told that the rule was one plugin per publication.
>>>> Therefore, I had already asked the plugin authors to make it that way for
>>>> this CMS analysis. Would you still accept it please, or do you want us to
>>>> split the files again? The plugin is essentially ready, just need one last
>>>> iteration before posting it here.
>>>>
>>>> Thanks in advance!
>>>>
>>>> Cheers,
>>>> Albert, Lars, Sara
>>>>
>>>>
>>>>
>>>> On 8/16/13 8:24 PM, Salvatore Rappoccio wrote:
>>>>> Hi, Andy,
>>>>>
>>>>> Thanks a lot for the quick response! We will work very hard in the
>>>>> coming week(s) to get this out the door.
>>>>>
>>>>> Cheers,
>>>>> Sal
>>>>>
>>>>> On Fri, Aug 16, 2013 at 10:48 AM, Andy Buckley <andy.buckley at cern.ch>
>>>>> wrote:
>>>>>> Yes, apologies that this wasn't clear. The "normal" situation is that
>>>>>> there is one analysis code per paper, because typically there is only
>>>>>> one process/topology type, but that rule is not absolute.
>>>>>>
>>>>>> The existence proof for this "split" analysis code is CDF's last
>>>>>> underlying event paper which was combined to cover both the QCD jet and
>>>>>> Drell-Yan event selections: this is in Rivet as the two analyses
>>>>>> CDF_2010_S8591881_QCD and CDF_2010_S8591881_DY. Using a similar naming
>>>>>> scheme for your analysis would be ideal... and of course ask us
>>>>>> (rivet at projects.hepforge.org) if you've got any questions.
>>>>>>
>>>>>> Best wishes,
>>>>>> Andy
>>>>>>
>>>>>> PS. I've included Lars Sonnenschein in the CC, as I think he has
>>>>>> recently replaced Albert as the CMS Rivet contact.
>>>>>>
>>>>>>
>>>>>> On 16/08/13 19:09, Salvatore Rappoccio wrote:
>>>>>>> Hi, All,
>>>>>>>
>>>>>>> There was some discussion at the BOOST workshop yesterday about this
>>>>>>> measurement's Rivet implementation. One thing that came up was that
>>>>>>> there need *not* be a one-to-one paper-to-routine mapping and that
>>>>>>> several routines can be made out of one paper. I think this would have
>>>>>>> helped enormously in this particular case, and having several
>>>>>>> topologies mapped into one routine has slowed this down tremendously.
>>>>>>>
>>>>>>> In the future, I would suggest that the CMS requirements change, and
>>>>>>> we allow for a routine for any given topology.
>>>>>>>
>>>>>>> In the short term, we need Nhan's final implementation with the
>>>>>>> current "multiple topologies" implementation, which will be
>>>>>>> forthcoming soon.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 18, 2013 at 2:18 AM, Albert Knutsson
>>>>>>> <albert.knutsson at cern.ch> wrote:
>>>>>>>> Hi Salvatore et al,
>>>>>>>>
>>>>>>>> thanks for your work with writing the rivet plugin.
>>>>>>>>
>>>>>>>>
>>>>>>>> Here are some things that come to my mind:
>>>>>>>>
>>>>>>>> * Please use rivet 1.8.2 it is available in CMSSW_5_3_9 and
>>>>>>>> CMSSW_6_2_0_pre2
>>>>>>>>
>>>>>>>> * It looks like you are missing the .aida, .info and .plot files.
>>>>>>>> Examples you find here:
>>>>>>>> /afs/cern.ch/sw/lcg/external/MCGenerators_hepmc2.06.08/rivet/1.8.1/share/sources/data/anainfo/
>>>>>>>>
>>>>>>>> /afs/cern.ch/sw/lcg/external/MCGenerators_hepmc2.06.08/rivet/1.8.1/share/sources/data/plotinfo/
>>>>>>>>
>>>>>>>> /afs/cern.ch/sw/lcg/external/MCGenerators_hepmc2.06.08/rivet/1.8.1/share/sources/data/refdata/
>>>>>>>>
>>>>>>>>
>>>>>>>> * Please also try take a look at Rivet coding conventions and the
>>>>>>>> feed back
>>>>>>>> from the rivet developers:
>>>>>>>> https://twiki.cern.ch/twiki/bin/viewauth/CMS/Rivet#General_feedback_to_CMS_from_the
>>>>>>>>
>>>>>>>> http://projects.hepforge.org/rivet/trac/wiki/CodingStyleGuide
>>>>>>>> (The rivet developers are very picky.)
>>>>>>>>
>>>>>>>> * For the validation CMS needs some validation plots. That is the
>>>>>>>> out put
>>>>>>>> from rivet compare to the data.
>>>>>>>>
>>>>>>>> There are more info on the our rivet twiki about all this.
>>>>>>>> https://twiki.cern.ch/twiki/bin/viewauth/CMS/Rivet
>>>>>>>>
>>>>>>>> Once you feel ready please send the files and plots to me and I
>>>>>>>> will do some
>>>>>>>> tests.
>>>>>>>>
>>>>>>>> We can also discuss on skype/vidyo if you need some more
>>>>>>>> guidance/help.
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Albert
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/15/13 5:52 PM, Salvatore Rappoccio wrote:
>>>>>>>>
>>>>>>>> Hi, Hannes,
>>>>>>>>
>>>>>>>> Thanks a lot! Albert, I'll follow the instructions.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sal
>>>>>>>>
>>>>>>>> On Fri, Mar 15, 2013 at 12:49 PM, Hannes Jung <hannes.jung at cern.ch>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Dear Salvatore et al
>>>>>>>>
>>>>>>>> I think Albert Knutsson (in cc) is the CMS responsible for Rivet.
>>>>>>>> He makes sure that the routines satisfy the standards and are properly
>>>>>>>> validated. So I think it is best to get in contact with him and follow
>>>>>>>> the advice on the CMS Twiki
>>>>>>>> https://twiki.cern.ch/twiki/bin/viewauth/CMS/Rivet
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Hannes
>>>>>>>>
>>>>>>>> On 15.03.2013, at 17:44, Salvatore Rappoccio wrote:
>>>>>>>>
>>>>>>>> Hi, All,
>>>>>>>>
>>>>>>>> We (at CMS) have completed a measurement of the jet mass in dijet and
>>>>>>>> V+jet events. We have a Rivet routine for the dijet analysis already
>>>>>>>> done (attached) and the V+jets in the works. We will have the data
>>>>>>>> uploaded to HEPData very soon.
>>>>>>>>
>>>>>>>> What are the steps we need to do in order to get this analysis
>>>>>>>> "riveted"?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Sal, Nhan, Kalanand, David for CMS
>>>>>>>> <MC_JETSTRUCTURE-1.cc>_______________________________________________
>>>>>>>> Rivet mailing list
>>>>>>>> Rivet at projects.hepforge.org
>>>>>>>> http://www.hepforge.org/lists/listinfo/rivet
>>>>>>>>
>>>>>>>>
>>>>>>>> ***********************************************************************
>>>>>>>>
>>>>>>>> Hannes Jung
>>>>>>>> Email: Hannes.Jung at desy.de
>>>>>>>> mobile :+49 40 8998 93741
>>>>>>>> http://www.desy.de/~jung
>>>>>>>> Tel: +49 (0) 40 8998 3741
>>>>>>>> Fax: +49 (0) 40 8994 3741
>>>>>>>> DESY, CMS 01B/02.213
>>>>>>>> Notkestr.85, 22603 Hamburg, FRG
>>>>>>>> ***********************************************************************
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Rivet mailing list
>>>>>>> Rivet at projects.hepforge.org
>>>>>>> http://www.hepforge.org/lists/listinfo/rivet
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dr Andy Buckley, Royal Society University Research Fellow
>>>>>> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dr Andy Buckley, Royal Society University Research Fellow
>>> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> http://www.hepforge.org/lists/listinfo/rivet
> 


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