[Rivet] ATLAS ttbar+jets analysis

[William Hamish Bell]

Hi,

I am back at CERN now.  I am working on the RIVET code again and should be finished quickly.

Best regards,

Will

On Aug 13, 2014, at 10:22 PM, 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
>>>>>>>>>>>>>> 
>> 
>