[Rivet] ATLAS ttbar+jets analysis

[Alexander Grohsjean]

Agreed, usually is not the proper word here. The point is that this 
overlap does not come from a "reconstruction/detector" problem, so you 
remove the complete event.
Yes, it is unfolded and the Rivet routine follows the selection of the 
paper.
( p20, 3rd paragraph of 7.1 of http://arxiv.org/pdf/1407.0891v1.pdf)

Cheers, Alexander.


Am 12.09.2014 um 22:36 schrieb Andy Buckley:
> On 12/09/14 20:30, Alexander Grohsjean wrote:
>> Dear Andy, dear Riccardo,
>>
>> at the detector-level we assume that jets overlapping with an electron
>> are in fact misidentified electrons, while muons overlapping with a jet
>> are muons from hadronic decays, so we don't count them as good muons.
>> These assumptions are based on the idea, that the original objects from
>> the ttbar decay usually don't overlap. Thus we veto events were this
>> happens at the truth-level.
>>
>> Does this make sense?
> I'm not sure how true it is that the objects don't tend to overlap in
> unbiased simulation, but isolation requirements are of course normal to
> keep the analysis both theoretically and experimentally clean.
>
> What really matters, though, is the truth definition used for unfolding
> the analysis (it is unfolded, right?). Did that use the whole-event
> vetoing in case of overlap?
>
> Andy
>
>
>> Am 12.09.2014 um 16:31 schrieb Andy Buckley:
>>> Can someone check Riccardo's concern? I am just merging the final ATLAS
>>> analyses into Rivet for the 2.2.0 release, so time is running out to get
>>> a correct version of this analysis into the release.
>>>
>>> Any news about the pseudojet observable cross-checking, Will?
>>>
>>> Andy
>>>
>>>
>>> On 11/09/14 10:11, Riccardo Di Sipio wrote:
>>>> Hi,
>>>>
>>>>      I think I need a clarification. In ATLAS_2014_I1304688.cc
>>>> L.121-139 I noticed that if the _overlap variable is set true, the
>>>> whole event is vetoed. I thought the action to take in such a case
>>>> was to remove the overlapping object, then proceed to cut on the good
>>>> final state objects (1 el/mu, >=4jets, btags, etc).
>>>>
>>>> Cheers,
>>>> Riccardo
>>>>
>>>>
>>>> On 10/set/2014, at 21:54, Andy Buckley <andy.buckley at cern.ch> wrote:
>>>>
>>>>> On 10/09/14 19:34, Dominic Hirschbühl wrote:
>>>>>> Hi Andy,
>>>>>>
>>>>>> it seems that we have some momentum to get our "top routines"
>>>>>> running in
>>>>>> Rivet 2.
>>>>> Indeed... and Thomas Balestri has already converted at least one of
>>>>> your
>>>>> v1 routines: not bad for one day!
>>>>>
>>>>>>   From discussion with Alexander and from your mails I got, that the
>>>>>> truth definitions from Will are  in the 2.2.0beta release.
>>>>>> We would like to change our routines to these definitions.
>>>>>>
>>>>>> Since we are working with EVGEN files, what is the timeline to get
>>>>>> this
>>>>>> release or 2.2.0 into Athena?
>>>>> We won't put the beta into Athena, but the remaining obstacles before
>>>>> releasing 2.2.0 are a few minor technical tweaks, copying in the newly
>>>>> submitted analyses, and validating against the previous release. I'm
>>>>> hoping to get it out next week, and then updating Athena to use that
>>>>> new
>>>>> release is easy.
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>> Am 03.09.2014 13:32, schrieb Andy Buckley:
>>>>>>> Thanks for letting us know, Will. We have a few technical tasks
>>>>>>> remaining before releasing Rivet 2.2.0 and I'll happily accept
>>>>>>> your code
>>>>>>> anytime before release (well, maybe not 5 mins before!)
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>
>>>>>>> On 03/09/14 10:33, William Hamish Bell wrote:
>>>>>>>> Hi Dominic,
>>>>>>>>
>>>>>>>> Yes, sure.  I have implemented the analysis in RIVET, using the
>>>>>>>> latest version of RIVET.  The code runs and the cut flow in the
>>>>>>>> code has been completely cross-checked against standalone code
>>>>>>>> running on the same data. The cut flow exactly agrees.  However,
>>>>>>>> the pseudo-top distributions do not agree with those in the
>>>>>>>> pseudo-top paper, despite being coded from the text of the paper
>>>>>>>> and internal note.  This is under urgent investigation.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Will
>>>>>>>>
>>>>>>>> ________________________________________
>>>>>>>> From: Dominic Hirschbuehl [dhirsch at mail.cern.ch]
>>>>>>>> Sent: 03 September 2014 11:29
>>>>>>>> To: William Hamish Bell
>>>>>>>> Cc: Alexander Josef Grohsjean; Andy Buckley; roman lysak; Rivet;
>>>>>>>> Kiran Joshi; hirsch at physik.uni-wuppertal.de
>>>>>>>> Subject: Re: [Rivet] ATLAS ttbar+jets analysis
>>>>>>>>
>>>>>>>> Hi Will,
>>>>>>>>
>>>>>>>> I have to give a status report in the MC generator meeting this
>>>>>>>> afternoon and tomorrow in the top meeting.
>>>>>>>>
>>>>>>>> Could you give me an update, where you are now with the pseduo
>>>>>>>> top now?
>>>>>>>>
>>>>>>>> Then I started to run Rivet myself on the various samples and I
>>>>>>>> try to
>>>>>>>> collect all routines we have for top processes, could you send me a
>>>>>>>> preliminary version as soon as possible?
>>>>>>>>
>>>>>>>> Thanks in advance
>>>>>>>>    Dominic
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 19, 2014 at 02:08:46PM +0000, William Hamish Bell wrote:
>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> /---------------------------------------------------------------------\
>>>>>>>>
>>>>>>>> |                     Dr. Dominic
>>>>>>>> Hirschbuehl                           |
>>>>>>>> \   Bergische Universitaet Wuppertal - Exp.
>>>>>>>> Elementarteilchenphysik   /
>>>>>>>> /  hirsch at physik.uni-wuppertal.de /
>>>>>>>> dominic.hirschbuehl at cern.ch       \
>>>>>>>> |       office : D.09.22    phone  : 0049 - 202 - 439 -
>>>>>>>> 3751           |
>>>>>>>> \---------------------------------------------------------------------/
>>>>>>>>
>>>>>>>>
>>>>> -- 
>>>>> Dr Andy Buckley, Royal Society University Research Fellow
>>>>> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>>>>> _______________________________________________
>>>>> Rivet mailing list
>>>>> Rivet at projects.hepforge.org
>>>>> https://www.hepforge.org/lists/listinfo/rivet
>