[Rivet] ATLAS ttbar+jets analysis

[William Hamish Bell]

Hi,

Please ignore the email below, the ATLAS_2014_I1304688.cc routine is 
fine.  The cut of 35GeV is used in the ttbar+jets paper but is not used 
in some other top group analyses, one of which I am currently validating.

Thanks and best regards,

Will

On 08/24/2014 09:59 AM, William Bell wrote:
> Hi,
>
> There is a mistake in
> Rivet-2.2.0beta1/src/Analyses/ATLAS_2014_I1304688.cc
>
> The MTW cut should be 30 GeV and not 35GeV.
>
> Best regards,
>
> Will
>
> On 13/08/2014 22:22, 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
>>>>>>>>>>>>>>>
>>>
>>
>