[Rivet] ATLAS ttbar+jets analysis

[Andy Buckley]

Thanks for letting us know, Will. We have a few technical tasks
remaining before releasing Rivet 2.2.0 and I'll happily accept your code
anytime before release (well, maybe not 5 mins before!)

Andy


On 03/09/14 10:33, William Hamish Bell wrote:
> Hi Dominic,
> 
> Yes, sure.  I have implemented the analysis in RIVET, using the latest version of RIVET.  The code runs and the cut flow in the code has been completely cross-checked against standalone code running on the same data.  The cut flow exactly agrees.  However, the pseudo-top distributions do not agree with those in the pseudo-top paper, despite being coded from the text of the paper and internal note.  This is under urgent investigation.
> 
> Best regards,
> 
> Will
> 
> ________________________________________
> From: Dominic Hirschbuehl [dhirsch at mail.cern.ch]
> Sent: 03 September 2014 11:29
> To: William Hamish Bell
> Cc: Alexander Josef Grohsjean; Andy Buckley; roman lysak; Rivet; Kiran Joshi; hirsch at physik.uni-wuppertal.de
> Subject: Re: [Rivet] ATLAS ttbar+jets analysis
> 
> Hi Will,
> 
> I have to give a status report in the MC generator meeting this
> afternoon and tomorrow in the top meeting.
> 
> Could you give me an update, where you are now with the pseduo top now?
> 
> Then I started to run Rivet myself on the various samples and I try to
> collect all routines we have for top processes, could you send me a
> preliminary version as soon as possible?
> 
> Thanks in advance
>   Dominic
> 
> 
> On Tue, Aug 19, 2014 at 02:08:46PM +0000, William Hamish Bell wrote:
>> Hi,
>>
>> I am back at CERN now.  I am working on the RIVET code again and should be finished quickly.
>>
>> Best regards,
>>
>> Will
>>
>> On Aug 13, 2014, at 10:22 PM, Alexander Grohsjean wrote:
>>
>>> Hi Andy, hi Will
>>>
>>> great! Thanks a lot!
>>> Regarding the pseudo-tops, maybe Will can comment as this is his
>>> analysis. My understanding is that with all the modifications we just made,
>>> it should be easy to provide. Will wanted to do it but then had to move house
>>> from Geneva to UK etc. So I have no news since then.
>>> It would be really great for us to have it and not use the parton-level tops!
>>>
>>> Cheers and thanks again, Alexander.
>>>
>>>
>>> Am 13.08.2014 um 18:55 schrieb Andy Buckley:
>>>> Thanks Alexander, that's great. I've merged it into the trunk of Rivet
>>>> now, and there should be a beta release of that for testing by the end
>>>> of the week.
>>>>
>>>> Do I hear that there is also a pseudo-top analysis that we could maybe
>>>> get in, too? Or anything else in the pipeline? Please get them to us
>>>> before the end of August if you want them in the 2.2.0 Rivet release.
>>>>
>>>> Andy
>>>>
>>>>
>>>> On 12/08/14 16:15, Alexander Grohsjean wrote:
>>>>> Hi Andy,
>>>>>
>>>>> sorry for the problems with the info file. I didn't test it.
>>>>> In fact, I never paid attention to all the features it has. :-)
>>>>> I hope everything is ok now. I tested it, added titles to the histos,
>>>>> and changed the ranges.
>>>>> Let me know in case there is something I missed.
>>>>>
>>>>> Cheers, Alexander.
>>>>>
>>>>>
>>>>>
>>>>> Am 11.08.2014 um 18:28 schrieb Andy Buckley:
>>>>>> Hi Alexander, all,
>>>>>>
>>>>>> Thanks. I had to fix some syntax errors in the .info file, however, in
>>>>>> order for it to parse and allow running. Did you ever actually test with
>>>>>> this .info?
>>>>>>
>>>>>> As requested, can you change the name of the analysis to the standard
>>>>>> format and update the .info file. As well as the typo (the second
>>>>>> reference is accidentally parsed as a map key due to a space after
>>>>>> "arXiv:"), there are some obvious errors like the ToDo key still being
>>>>>> present, the analysis being marked as UNVALIDATED, and I think what is
>>>>>> listed as SpiresID should actually be InspireID (and the analysis should
>>>>>> be named accordingly with an S or an I according to whether the number
>>>>>> is SPIRES or Inspire: the latter is now strongly preferred.) There might
>>>>>> be more...
>>>>>>
>>>>>> Thanks again -- once you get me these updated metadata files I will
>>>>>> merge this into version control for the next version of Rivet.
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>> On 11/08/14 14:25, Alexander Grohsjean wrote:
>>>>>>> Hi Andy,
>>>>>>>
>>>>>>> please find the files attached.
>>>>>>> Looks like they were lost in all the emails.
>>>>>>> The analysis is on arXiv, so public.
>>>>>>>
>>>>>>> Thanks again for all the work.
>>>>>>> Cheers, Alexander.
>>>>>>>
>>>>>>>
>>>>>>> Am 11.08.2014 um 15:16 schrieb Andy Buckley:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I've added the FromElectroweakDecay to the release branch for Rivet
>>>>>>>> 2.2.0 with the name PromptFinalState. I had to make a few tweaks to it,
>>>>>>>> since e.g. the compare method wasn't accounting for the "accept tau
>>>>>>>> decays" flag and there were some possible generator-specific ways for
>>>>>>>> the classification logic to go wrong... but basically it went in
>>>>>>>> without
>>>>>>>> problems. Thanks!
>>>>>>>>
>>>>>>>> I've modified the ATLAS_ttjets analysis code to fit with our coding
>>>>>>>> standards etc., make use of a few more Rivet code convenience features
>>>>>>>> and the sortByPt function, and to use the new ghost b-tagging that I
>>>>>>>> wrote last week. I've attached a copy of that for your information.
>>>>>>>>
>>>>>>>> I don't think I messed anything up, but it needs to be tested to be
>>>>>>>> certain. I didn't find a .info, .plot, or .yoda reference file in the
>>>>>>>> tarball and will need at least the last of these to do some testing.
>>>>>>>> Finally, is this analysis allowed to go public yet? If so, it will need
>>>>>>>> the name to be changed to the standard scheme ATLAS_2013_Ixxxxxx scheme
>>>>>>>> -- I can do that for the .cc file if you're otherwise happy with it,
>>>>>>>> but
>>>>>>>> would appreciate if you can supply the .info and .plot in the final
>>>>>>>> form.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andy
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/08/14 10:15, Alexander Grohsjean wrote:
>>>>>>>>> Thanks Andy!
>>>>>>>>> Cheers, Alexander.
>>>>>>>>>
>>>>>>>>> Am 09.08.2014 um 23:31 schrieb Andy Buckley:
>>>>>>>>>> On 22/07/14 15:49, Alexander Grohsjean wrote:
>>>>>>>>>>> Dear Andy, dear all,
>>>>>>>>>>>
>>>>>>>>>>> I checked out the dev version and modified my stuff to get it
>>>>>>>>>>> working.
>>>>>>>>>>> (mainly ClusteredLepton was changed to DressedLepton).
>>>>>>>>>>> Attached you can find my modified/added files that are running in
>>>>>>>>>>> this
>>>>>>>>>>> version.
>>>>>>>>>>>
>>>>>>>>>>> There are 3 points which affect rivet in general (except the new
>>>>>>>>>>> projection), so I added this to the README but would like to
>>>>>>>>>>> discuss it
>>>>>>>>>>> now.
>>>>>>>>>>> I added a p T sorting to dressedleptons, something that I couldn't
>>>>>>>>>>> find.
>>>>>>>>>>> If it is not my mistake and I missed it, I think
>>>>>>>>>>> that is something usefull to add as other projections can be sorted.
>>>>>>>>>> There are already sorting routines, including sortByPt, for all
>>>>>>>>>> containers of classes that behave like FourMomentum. I'll change the
>>>>>>>>>> code to do that.
>>>>>>>>>>
>>>>>>>>>>> I changed the containsb function in Jet.cc to include ghost
>>>>>>>>>>> tagging. Not
>>>>>>>>>>> sure how you like to get this into rivet.
>>>>>>>>>>> There are various way of doing it and I am sure you have a prefered
>>>>>>>>>>> option. You can easily follow my modifications,
>>>>>>>>>>> there are detailed in the file. Same for adding the ghost b
>>>>>>>>>>> hadrons in
>>>>>>>>>>> FastJets.cc. Maybe you also want to have the same
>>>>>>>>>>> for c jets?
>>>>>>>>>> Yes, this was started a long time ago by James Monk but was never
>>>>>>>>>> finished. I rewrote it last week along with other Rivet::Jet /
>>>>>>>>>> fastjet::PseudoJet interoperability improvements, and it also does c
>>>>>>>>>> and
>>>>>>>>>> tau tagging, so I should just be able to use that functionality
>>>>>>>>>> directly
>>>>>>>>>> and skip these patches.
>>>>>>>>>>
>>>>>>>>>>> Not sure what I can check with Roman apart from the validation I
>>>>>>>>>>> already
>>>>>>>>>>> did (object level for 5000 events looking at jets, leptons, cuts
>>>>>>>>>>> and
>>>>>>>>>>> the final plots I provided)?
>>>>>>>>>>> Maybe it is useful to run, once everything is in, on a small sample
>>>>>>>>>>> and
>>>>>>>>>>> check it, but apart from that,
>>>>>>>>>>> I am not sure I can do more. Let me know.
>>>>>>>>>> Sounds like it's already sorted. Thanks.
>>>>>>>>>>
>>>>>>>>>>> Regarding the jet gap fraction analysis. Officially (rivet page)
>>>>>>>>>>> it is
>>>>>>>>>>> clearly written that one needs dilepton events.
>>>>>>>>>>> The problem with the projection was when running on at least one
>>>>>>>>>>> lepton
>>>>>>>>>>> events, like we have them usually in ttbar @ 7 TeV.
>>>>>>>>>>> I assume Kiran et al. were using a home-made filter. In that case
>>>>>>>>>>> there
>>>>>>>>>>> is no problem.
>>>>>>>>>>> Now if you are running on ttbar events without filter, the
>>>>>>>>>>> projection
>>>>>>>>>>> would select you ll events and you can compare it with the data we
>>>>>>>>>>> have.
>>>>>>>>>>> But from a technical point everything is ok, the page clearly says
>>>>>>>>>>> dilepton.
>>>>>>>>>> Thanks again. I also discussed this in an MC physics / tuning meeting
>>>>>>>>>> with Stefano Camarda, to see if there would be a way to run this
>>>>>>>>>> analysis before the new Rivet is available. Seems not -- which is
>>>>>>>>>> ok, I
>>>>>>>>>> just wanted to know if there was a pragmatic shortcut to get it into
>>>>>>>>>> tuning asap.
>>>>>>>>>>
>>>>>>>>>> I'll merge in a version of FromElectroweakDecay now, and let you
>>>>>>>>>> know if
>>>>>>>>>> I've got any more questions. Thanks.
>>>>>>>>>>
>>>>>>>>>> Andy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Am 22.07.2014 13:33, schrieb Andy Buckley:
>>>>>>>>>>>> On 22/07/14 11:56, Alexander Grohsjean wrote:
>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was prodividing the tools that we changed in a tar bal with
>>>>>>>>>>>>> just the
>>>>>>>>>>>>> modified/added files.
>>>>>>>>>>>>> I summarized quickly the changes in a README in the main path.
>>>>>>>>>>>>> So I must admit that I am not sure what is missing here. Diff
>>>>>>>>>>>>> should be
>>>>>>>>>>>>> very easy to run and to
>>>>>>>>>>>>> see the changes providing this?
>>>>>>>>>>>> The issue is that we need a minimal diff against the latest
>>>>>>>>>>>> version --
>>>>>>>>>>>> ideally against the 2.1.x branch head since other things have
>>>>>>>>>>>> changed
>>>>>>>>>>>> and we don't want to just copy your files in place and overwrite
>>>>>>>>>>>> those
>>>>>>>>>>>> other developments.
>>>>>>>>>>>>
>>>>>>>>>>>>> Changing names "FromElecroweakDecay" is perfectly fine with us,
>>>>>>>>>>>>> these
>>>>>>>>>>>>> were
>>>>>>>>>>>>> just historically.
>>>>>>>>>>>>> I started developing in 2.1.0, then updated to 2.1.1 at some
>>>>>>>>>>>>> point but
>>>>>>>>>>>>> didn't switch to 2.1.2 as this happened after my validation.
>>>>>>>>>>>>> Should I
>>>>>>>>>>>>> now run it
>>>>>>>>>>>>> in 2.1.2?
>>>>>>>>>>>> Since it's not just a new analysis, working from the *development*
>>>>>>>>>>>> version (i.e. the target for 2.1.3, which has evolved since 2.1.2)
>>>>>>>>>>>> would
>>>>>>>>>>>> help us a lot with integrating these changes.
>>>>>>>>>>>>
>>>>>>>>>>>> You can get the branch head like this:
>>>>>>>>>>>> hg clone https://rivet.hepforge.org/hg/rivet -b release-2-0
>>>>>>>>>>>> then make changes and commit them if you need, and point us at your
>>>>>>>>>>>> cloned repo when ready. Ask if you have any questions!
>>>>>>>>>>>>
>>>>>>>>>>>>> For validation, I attached the same distributions that we have in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> paper (blue and red with ct10).
>>>>>>>>>>>>> Should I provide the log-files from object by object comparisons?
>>>>>>>>>>>>> These are the internal notes:
>>>>>>>>>>>>> Jet multiplicity supporting note
>>>>>>>>>>>>> https://cds.cern.ch/record/1532076
>>>>>>>>>>>>> Jet pT supporting note
>>>>>>>>>>>>> https://cds.cern.ch/record/1545583
>>>>>>>>>>>> I think that's for ATLAS internal validation purposes... I'm
>>>>>>>>>>>> wearing my
>>>>>>>>>>>> Rivet hat here, which means that I assume you and Roman have
>>>>>>>>>>>> checked
>>>>>>>>>>>> everything and we just need to deal with the technicalities.
>>>>>>>>>>>> Although
>>>>>>>>>>>> since there are new projections we will be pickier than with just
>>>>>>>>>>>> accepting a new analysis ;-)
>>>>>>>>>>>>
>>>>>>>>>>>> By the way, I saw a report from Stefano Camarda that at least the
>>>>>>>>>>>> important ttbar jet veto analysis (and maybe also the ttbar jet
>>>>>>>>>>>> shapes)
>>>>>>>>>>>> do not properly require "prompt" leptons and hence the results
>>>>>>>>>>>> differ
>>>>>>>>>>>> due to the allowed W decay channels. Could you also fix these to
>>>>>>>>>>>> use
>>>>>>>>>>>> the
>>>>>>>>>>>> FromElectroweakDecay projection?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Andy
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 21.07.2014 20:59, schrieb roman lysak:
>>>>>>>>>>>>>>       Hi Andy,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 21/07/14 16:14, Andy Buckley wrote:
>>>>>>>>>>>>>>> Hi Roman,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've seen this analysis already and realised the issue. This
>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>> where it would have been nice if we could have worked with the
>>>>>>>>>>>>>>> authors
>>>>>>>>>>>>>>> to discuss the new projections and get them directly into the
>>>>>>>>>>>>>>> Rivet
>>>>>>>>>>>>>>> trunk rather than need to do it retrospectively.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It would help us if you/they could provide diffs with respect
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> latest Rivet version -- have these modifications been made on
>>>>>>>>>>>>>>> top of
>>>>>>>>>>>>>>> version 2.1.2?
>>>>>>>>>>>>>> they have been made w.r.t. version 2.1.1, as far as I know.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       We need to make sure that we don't undo our own
>>>>>>>>>>>>>>> developments when merging this. Having looked at the source
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> FromElectroweakDecay projection, it doesn't actually do what
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>> suggests, so I would like to change that to match the sort of
>>>>>>>>>>>>>>> scheme
>>>>>>>>>>>>>>> that we've used for Particle.fromDecay(), or perhaps define
>>>>>>>>>>>>>>> IsPrompt /
>>>>>>>>>>>>>>> IsNonPrompt particle classifiers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Getting a new Rivet out with these features and some others in
>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the BOOST conference in mid-August is high on my priority
>>>>>>>>>>>>>>> list, so
>>>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>> be back in touch. But if you can talk with Will and Alexander
>>>>>>>>>>>>>>> (right?)
>>>>>>>>>>>>>> right, cc-ing to them, so that the communication is hopefully
>>>>>>>>>>>>>> quicker
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to make minimal patches (or ideally an hg branch that we can
>>>>>>>>>>>>>>> clone,
>>>>>>>>>>>>>>> modify and merge) that we can apply, that would help a lot.
>>>>>>>>>>>>>> Alex, Will, could you try to do as suggested by Andy, i.e. at
>>>>>>>>>>>>>> least
>>>>>>>>>>>>>> try to compare to Rivet 2.1.2?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks a lot,
>>>>>>>>>>>>>>       Roman
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 21/07/14 15:03, Roman Lysak wrote:
>>>>>>>>>>>>>>>>        Dear Rivet authors,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in ATLAS, we've got another analysis we would like to
>>>>>>>>>>>>>>>> eventually
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>> included into Rivet (right now, it's being validated):
>>>>>>>>>>>>>>>> ttbar+jets
>>>>>>>>>>>>>>>> analysis.
>>>>>>>>>>>>>>>> However, while implementing this analysis, the authors made
>>>>>>>>>>>>>>>> changes to
>>>>>>>>>>>>>>>> some core Rivet routines (FastJet, Jet, and DressedLepton
>>>>>>>>>>>>>>>> projections)
>>>>>>>>>>>>>>>> and also added one new Projection (FromElectroweakDecay). I'm
>>>>>>>>>>>>>>>> attaching
>>>>>>>>>>>>>>>> the changes they made.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We would like to ask you, what would be the best way to
>>>>>>>>>>>>>>>> proceed:
>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>> you would be willing to accept any of the updates to the core
>>>>>>>>>>>>>>>> routines
>>>>>>>>>>>>>>>> or you would prefer to have everything implemented inside the
>>>>>>>>>>>>>>>> analysis
>>>>>>>>>>>>>>>> routine (in the second case, the validation/re-validation will
>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>> take longer, obviously :)).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>        Roman
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Rivet mailing list
>>>>>>>>>>>>>>>> Rivet at projects.hepforge.org
>>>>>>>>>>>>>>>> https://www.hepforge.org/lists/listinfo/rivet
>>>>>>>>>>>>>>>>
>>>>
>>>
>>
> 
> --
>  /---------------------------------------------------------------------\
> |                     Dr. Dominic Hirschbuehl                           |
>  \   Bergische Universitaet Wuppertal - Exp. Elementarteilchenphysik   /
>  /  hirsch at physik.uni-wuppertal.de / dominic.hirschbuehl at cern.ch       \
> |       office : D.09.22    phone  : 0049 - 202 - 439 - 3751           |
>  \---------------------------------------------------------------------/
> 


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