|
[Rivet] ATLAS ttbar+jets analysisAndy Buckley andy.buckley at cern.chFri Aug 29 13:58:42 BST 2014
Ok, reverted. On 27/08/14 19:23, William Hamish Bell wrote: > Hi, > > Please ignore the email below, the ATLAS_2014_I1304688.cc routine is > fine. The cut of 35GeV is used in the ttbar+jets paper but is not used > in some other top group analyses, one of which I am currently validating. > > Thanks and best regards, > > Will > > On 08/24/2014 09:59 AM, William Bell wrote: >> Hi, >> >> There is a mistake in >> Rivet-2.2.0beta1/src/Analyses/ATLAS_2014_I1304688.cc >> >> The MTW cut should be 30 GeV and not 35GeV. >> >> Best regards, >> >> Will >> >> On 13/08/2014 22:22, 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 Andy Buckley, Royal Society University Research Fellow Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
More information about the Rivet mailing list |