|
[Rivet] ATLAS ttbar+jets analysisRiccardo Di Sipio Riccardo.DiSipio at bo.infn.itSat Sep 13 09:32:55 BST 2014
Hi, to me this is fine. I just wanted to make sure that this Rivet routine reproduces as close as possible what is done in the analysis, as it is supposed to do. Cheers, Riccardo On 13/set/2014, at 00:01, Alexander Grohsjean <Alexander.Grohsjean at desy.de> wrote: > 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 >> >
More information about the Rivet mailing list |