[Rivet] CMS RIVET analyses

[Hannes Jung]

Dear Nhan (cc Andy et al)

I just forward this mail thread to our Rivet coordinators  Lars & Albert

Cheers
Hannes

On 22.11.2013, at 18:16, Nhan V Tran <ntran at fnal.gov> wrote:

> Hi Andy,
> 
> Thanks for the detailed reply!  More inline...
> 
>>> Thanks for following up on the CMS jet mass RIVET routine last week.  I forgot to ask you, one of the other CMS conveners was asking me...
>>> 
>>> Can you let me know what CMS analyses are in the RIVET queue and what's the expected time to be included?
>> 
>> Hi Nhan, (and CC'ing the Rivet dev list)
>> 
>> I finally got time today to really spend some time on incorporating the
>> various new analyses for Rivet 1.8.4. We'll release this very soon,
>> followed as soon as we can by an equivalent 2.0.1.
>> 
>> There are two CMS analyses in our queue: your jet mass one, and
>> CMS_2013_I1258128.cc (rapidity distributions in Z+jet and gamma+jet
>> events). If there are more that we can include right away, now is the
>> time to let us know!
> 
> Thanks, will let you know if there are any other CMS requests.
> 
>> I have a few questions/comments about your analysis, actually: we don't
>> just copy them into place but do a bit of code checking and clean-up
>> first... which is why it's usually not a 100% straightforward operation.
>> A bit annoying, I know, but once we've got them in the system we have to
>> maintain them... hence we sometimes ask for fixes and clarifications!
>> Ok, here goes:
> 
> Thanks for taking the time.  This is our first RIVET analysis, so I'm very happy to have an expert take a look ;)...
> 
>> * I've split the analysis into three separate analyses, with _ZJET,
>> _WJET, and _DIJET suffixes. The _ZJET one is the one that I've tidied up
>> so far (e.g. putting the pT bin searching into a function really
>> compresses the code blocks for the three jet types), and I've attached
>> it for your interest. (It quite possibly doesn't compile right now: it's
>> the code logic that I'd like feedback on, if you have any.)
> 
> This is perfect for me. 
> 
>> * 2D histos will coming soon in Rivet v2 / YODA. They are an order of
>> magnitude more fiddly than 1D ones, if you really want to handle
>> overflows and so-on nicely. I though that they worked already in Rivet
>> v1, though... but HepData doesn't (yet) support them so I think this 1D
>> slice approach is better anyway.
> 
> I agree, it's fine to keep the 1D slides.  
> 
>> * There is a bit of code to treat any negative weights as equivalent to
>> 1.0. Why is that? I expect it's a bad idea, especially with more NLO
>> simulations becoming normal, but I wanted to check rather than just
>> remove it.
> 
> I think it's fine to remove.  I'm not sure if it was there for some protection (Sal put this in), but you make a good point about the NLO simulations.
> 
>> * The back-to-back requirement between the W/Z and the leading jet i
>> actually applied in reverse:
>> 
>> // Get the leading jet and make sure it's back-to-back with the Z
>> const fastjet::PseudoJet& j0 = psjetsCA8_zj[0];
>> if (!isBackToBack_zj(zfinder, j0)) { //< @todo ARGH!?!
>> 
>> (This is my tidied version of the code, but I checked that this isn't a
>> problem that I introduced!) Is this a (repeated) typo, or is the
>> back-to-back cut *really* meant to work this way round? (Which would be
>> strange.) The isBackToBack function contents do match its name.
> 
> Good catch, please reverse it! 
> 
>> * Lastly, something on which we'll maybe need input from other Rivet
>> developers: you're using explicitly FastJet3 functionality to groom the
>> jets. That's great: you've written the first official experiment Rivet
>> analysis to require FJ3! But it means that we will need to require FJ3
>> for any Rivet version which includes this analysis... which we currently
>> don't do. I think we can happily do that for Rivet version 2, but
>> perhaps it's not the best idea to make that change in our last ever 1.x
>> minor version.
>> 
>> I suggest that we release Rivet 1.x with the existing FJ > 2.x
>> requirement, and also make your analysis code public on the Rivet
>> website for FJ3 users to build. Or we could make a special exception and
>> build the analysis only if FJ2 is present: that might be the neatest
>> option. For Rivet 2.0.1 we can make FJ3 a build requirement: I think it
>> is time for that anyway, but thanks for giving us a concrete reason to
>> do so!
> 
> I have seen the continuing thread from the other developers and your solution sounds good for me
> 
> Thanks a lot!
> Best,
> Nhan
> 
> 
>> 
>> Cheers, and please let me know about those queries in the code and if
>> you have any other feedback on the "tidied" version: once I know what to
>> do I'll carry on doing similar tidying for the _DIJET and _WJET source
>> files.
>> 
>> Andy
>> 
>> -- 
>> Dr Andy Buckley, Royal Society University Research Fellow
>> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>> <CMS_2013_I1224539_ZJET.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   
***********************************************************************