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

[Andy Buckley]

On 23/09/13 15:53, Nhan V Tran wrote:
> Hi all,
> 
> Right now it is written as one analyzer and it is just like Andy says: it always has to be run as if separate ones and the user just needs to understand that the empty histograms are to be ignored (though the histogram labels make that clear).  For that matter, it is also important to note that it's not two separate analyses, but in fact, three -- dijets, W+jets, Z+jets -- which all should be run separately.  Unless there are any objections, I'll try splitting it in 3 and seeing if any technical problems arise**.

Ok, sounds good to me! I just finished some of the last tasks needed for
our Rivet 2.0 release, so we should have that soon, and then a final
release of the 1.8.x series in the next couple of weeks to incorporate
the final submitted analyses. Do you think this set of 3 analyses could
be got to us in time for that? We can delay a bit, if necessary, but it
would be nice for us to be able to concentrate solely on version 2 as
soon as possible.

> ** For example, as a RIVET novice, it wasn't clear to me how to turn off histograms in the aida file since HEPMC aida stores all 3 analyses together.  But when it comes to this, I'll ask the CMS technical team.

If you're doing all three analyses in one routine then there is not
really a way to do that: because there isn't a robust way to determine
the process which is being run we didn't provide a hook to do tests in
the init() method. It could maybe be hacked around, but please don't ;-)
 For determining the beam energy, which commonly specifies which plots
are to be made, we *do* provide such a hook: the sqrtS() function takes
an advance look at the first event in the run. But for more ambiguous
things like this I think it's better to split the analysis to reflect
how it will be run.

Thanks!
Andy


> On Sep 23, 2013, at 7:06 AM, Salvatore Rappoccio wrote:
> 
>> Hi, Andy, All,
>>
>> OK, so it sounds like two files are better, then. Nhan, looks like the
>> ball is with you again, sorry. Hehe.
>>
>> Cheers,
>> Sal
>>
>>
>> On Mon, Sep 23, 2013 at 6:53 AM, Andy Buckley <andy.buckley at cern.ch> wrote:
>>> 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
> 


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