[Rivet] ATLAS ttbar+jets analysis

[Andy Buckley]

Just tested the analysis on 10k Pythia8 ttbar events. Ran fine, and
looks compatible with the validation that you supplied.

Can you please add Title attributes to the histograms?

Some of them are also set to have XMax attributes which are larger than
the maximum bin, which looks strange: it's fine for histo (1,1,1) with
max edge at 8.5 but the same rule is applied to (1,{2,3,4},1) have max
bin edges at 7.5, 6.5 and 5.5 respectively. It will plot fine without
the XMax attribute, so was there a reason to force the same max in all
cases even though the binning changes?

Andy


On 11/08/14 17:28, Andy Buckley wrote:
> 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 Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN