<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> </head> <body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div> </div> <div>oh right, that is the answer for this case. I run this analysis in a chain with other analyses and Kaon/Lambdas are stable.... no doubt. it seems that it works fine with a sample where we have Kaons with status 2. </div> <div> </div> <div>Cheers </div> <div>Sercan,</div> <div> </div> <div> </div> <div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> </div> </div> </div> <div> <div>On Oct 26, 2012, at 2:03 PM, Frank Siegert wrote:</div> <blockquote type="cite"> <div>Hi Sercan, So this basically means that in your sample the K_S (and Lambda?) have been set stable and don't decay. Currently, the analysis requires them to have a given range of transverse flight distance before decaying, so clearly this kind of analysis can't be used with Monte-Carlo samples that set the K_S and Lambda stable. Whether this implementation (cutting on flight distance at the particle level) is correct for that analysis would have to be answered by somebody more familiar with it -- Emily? Frank On 26 October 2012 13:13, Sercan Sen <<a href="mailto:Sercan.Sen@cern.ch">Sercan.Sen@cern.ch</a>> wrote: <blockquote type="cite"> </blockquote> <blockquote type="cite">Hello Frank, </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">I didn't run this analysis before. However, I have been running some other </blockquote> <blockquote type="cite">analyses and add this one to the chain now to see if there is any </blockquote> <blockquote type="cite">difference. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">I've just run over 150K events (INEL Z2*) both the previous version and the </blockquote> <blockquote type="cite">new version in the trunk, but there is no event survive. Most of the events </blockquote> <blockquote type="cite">are rejected by the flightDistance cut of Kaon/Lambda which always returns </blockquote> <blockquote type="cite">as 1e+07. with hepmc 2.06.08 and unit is mm.. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Just for my curiosity, I debug a little bit and return the pdg id of the </blockquote> <blockquote type="cite">particle from getPerpFlightDistance function where it truly returns this </blockquote> <blockquote type="cite">before the "if (decV)" scope. Events never go inside decV scope and </blockquote> <blockquote type="cite">therefore the value of the flighttd which is 1e+07 is dummy in the current </blockquote> <blockquote type="cite">code. So, all events are failed... </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">by the way, as expected we have more events after the correction on the MBTS </blockquote> <blockquote type="cite">cuts and I think this will not be only statistical effect. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">* ================== </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">OLD VERSION </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Cross-section = 7.130367e+10 pb </blockquote> <blockquote type="cite">Rivet.Analysis.Handler: INFO Finalising analyses </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO Events that pass the trigger: </blockquote> <blockquote type="cite">112103 </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO Kshort events: 0 </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO Lambda events: 0 </blockquote> <blockquote type="cite">Rivet.Analysis.Handler: INFO Processed 150000 events </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">NEW VERSION </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Cross-section = 7.130367e+10 pb </blockquote> <blockquote type="cite">Rivet.Analysis.Handler: INFO Finalising analyses </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO Events that pass the trigger: </blockquote> <blockquote type="cite">127174 </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO Kshort events: 0 </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO Lambda events: 0 </blockquote> <blockquote type="cite">Rivet.Analysis.ATLAS_2011_I944826: INFO This is the modified analysis, </blockquote> <blockquote type="cite">revision 3975 </blockquote> <blockquote type="cite">Rivet.Analysis.Handler: INFO Processed 150000 events </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Thanks, </blockquote> <blockquote type="cite">Sercan </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">On Oct 25, 2012, at 3:36 PM, Frank Siegert wrote: </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Hi Sercan, </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Thanks again for the feedback. I have implemented the changes in changeset </blockquote> <blockquote type="cite">3975: </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"><a href="http://rivet.hepforge.org/trac/changeset/3975">http://rivet.hepforge.org/trac/changeset/3975</a> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">I don't have any possibility to test whether this does something </blockquote> <blockquote type="cite">significantly different from before though. Sercan or Holger, since </blockquote> <blockquote type="cite">you are probably the only two on this list who have run this analysis </blockquote> <blockquote type="cite">before, do you have any chance to check with these changes? </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Cheers, </blockquote> <blockquote type="cite">Frank </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">On 24 October 2012 11:31, Sercan Sen <<a href="mailto:Sercan.Sen@cern.ch">Sercan.Sen@cern.ch</a>> wrote: </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Hi Frank, </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">what about the "nstable" requirement... does that only look at </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">particles >100 MeV? </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">yes, this is what I understand from the paper -- and it's reasonable. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">trigger cut is 2.09 < |\eta| < 3.84 </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">analysis cuts: |\eta| < 2.5, 100*MeV, .... </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">I think the best way is to use another projection for the trigger </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">requirement. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Cheers, </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Sercan </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">On Oct 23, 2012, at 3:47 PM, Frank Siegert wrote: </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Hi Sercan, </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Right. "nstable" part should be in |\eta| < 2.5 . So, if we extend the </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">rapidity acceptance in the CFS projection, then we should apply a rapidity </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">cut in the "nstable" part.. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Thanks for the clarification. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">By the way, I don't know if we need 100*MeV for ATLAS MBTS requirement (this </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">is applied in the current code) ? Probably, we don't need it but this should </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">be checked by someone from ATLAS.. </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Then again the same follow-up question: If the 100 MeV is not </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">necessary for the MBTS trigger requirement (pending confirmation by </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Emily), what about the "nstable" requirement... does that only look at </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">particles >100 MeV? </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Cheers, </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite">Frank </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> <blockquote type="cite"> </blockquote> </div> </blockquote> </div> </body> </html>