[Rivet] ATLAS ttbar+jets analysis

Alexander Grohsjean Alexander.Grohsjean at desy.de
Mon Aug 11 10:15:47 BST 2014


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
>>>>>>>
>



More information about the Rivet mailing list