[Rivet] ATLAS ttbar+jets analysis

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


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN