[Rivet] CMS RIVET analyses

[Nhan V Tran]

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>