[Rivet] ATLAS ttbar+jets analysis

[Alexander Grohsjean]

Hi Andy,

I did it consistent with the paper layout. But for Rivet,
this can be dropped.

Cheers, Alexander.


Am 11.08.2014 um 18:43 schrieb 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
>>>>>>>>>>>>
>>
>