[Rivet] ATLAS ttbar+jets analysis

[Alexander Grohsjean]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.tar.gz
Type: application/x-gzip
Size: 2447 bytes
Desc: not available
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20140812/5c70509b/attachment.bin>