Review of the paper on ReDecay

This page is intended to gather the information on the review process of the paper. All versions can be found below.

Preliminary list of proponents

Marco Clemencic, Gloria Corti, Marco Gersabeck, and Dominik Muller

Underlying event terminology

We are discussing changing the terminology as 'underlying event' is ambiguous.

Draft v1

In the following, questions raised during the review are collected and answers are given. Editorial comments can be found in the attached files and will be incorporated in the next draft.

Title - could consider making it a bit more… exciting e.g. “ReDecay: A novel approach to speed up the simulation at LHCb” (Mark Whitehead)

I definitely agree and am happy to make this change for the next draft.

Just to check I followed the bootstrapping part - for the ReDecay sample you effectively bootstrap twice, firstly choosing the blocks and then choosing the events within each block? (Mark Whitehead)

You can sample twice, i.e. sample blocks and then sample events within the drawn blocks. However, the second sampling is not necessary. Not doing it and only sampling blocks leads to the same answer for large numbers of blocks and bootstrap samples. I think that is also discussed in the reference. This also applies to block bootstrapping on independent data, where one simply assigns events to groups randomly. Small demonstration:

l. 85: « practically » : aren’t the signal particles completely identical ? Why do you write they are *almost the same ?* (Patrick Robbe)

This is true for the truth information. The reconstructed kinematics of the parent particle are affected by resolution effects creating a small degree of variation. I propose to expand the sentence accordingly to highlight this.

l. 134 and after: I am not sure I understand what you mean by « drawn with replacement » Do you mean « re-placement » ie that the same events can be drawn several times since they are placed again in the original sample ? Or « replacement » that the events replace something else ? (Patrick Robbe)

The former and to my knowledge 'sampling with replacement' is the common stat term for such a random process.

l. 148: « has reach a size of N’ entries » : does this mean that if the last drawn block is too large it is truncated to fit N’ entries ? (Patrick Robbe)

That is what I currently do but in any sensible scenario (with a 1000s of blocks) I am sure it is irrelevant whether this is done.

l. 168: « Monte Carlo sample productions » : maybe you could add a number here,, for example of events produced per month with this method (Patrick Robbe)

Yes, we could certainly add a number from here We should make sure that we send the right message though.

l. 173: 95% of the time : do you also include digitisation + reconstruction + the rest of the processing ? (Patrick Robbe)

No, these numbers have been estimated from the Gauss timing alone. However, I think that it should be changed to "In this configuration and depending on the simulated decay, around 95% ..." to highlight that this number depends on multiple factors and isn't fixed.

Draft v2

l. 21: I was wondering here why you mention D0 —> K pi rather than decay of Ref. 1. I understand that you want to discuss in context of yCP, so perhaps one could mention both and give references to both (for yCP for now we can say paper in preparation and in future update we can change reference to arXiv and/or journal). (Michal Krebs)

We have added the second decay as in reference [1] as an example. Concerning yCP, I would ideally cite it in the summary but personally I'd prefer the paper using ReDecay to cite this paper if we get the timing right and avoid circular citations.

l. 37-40: I’m wondering whether one could give typical number of particles in rest of event to allow reader judge scale. (Michal Krebs)

We state the typical events contain hundreds of particles at the beginning of the paragraph (l. 30) compared to a few in the signal.

l. 36: Maybe change "signal process” to “process of interest” (I did not check whether there is implication of this change on rest of the text). (Michal Krebs)

I think signal process is a well-defined label in HEP and I prefer to keep it (also, it is used in a lot of places in the paper)

l. 154: As you are talking about bootstrapping by blocks but your N’ is defined in terms of number of events, in resampling you are not going to get exactly N’ events. I’m wondering whether after introducing bootstrapping by blocks one could reformulate also N’ in terms of blocks. (Michal Krebs)

We state that we sample blocks until N' events are reached (with the last block potentially being chopped off). In practice it doesn't make a difference anyway for larger N and Nblocks.

Draft v3

Only received corrections for typos from Gloria Corti and Mark Whitehead. Thank you!

Draft v4.x

Iterations modifying Acknowledgments and title page.

Draft v5

Added reference to yCP paper in summary

Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt comments_michael_krebs_v2.txt r1 manage 2.2 K 2018-10-08 - 11:08 DominikMueller  
Texttxt comments_patrick_robbe_v1.txt r3 r2 r1 manage 7.1 K 2018-09-14 - 14:21 DominikMueller  
PDFpdf draftv1.pdf r1 manage 619.1 K 2018-08-29 - 17:51 DominikMueller  
PDFpdf draftv2.pdf r1 manage 610.6 K 2018-09-28 - 13:57 DominikMueller  
PDFpdf draftv3.pdf r1 manage 632.0 K 2018-10-08 - 14:23 DominikMueller  
PDFpdf draftv4.1.pdf r1 manage 631.8 K 2018-10-11 - 16:55 DominikMueller  
PDFpdf draftv4.2.pdf r3 r2 r1 manage 631.5 K 2018-10-12 - 13:01 DominikMueller  
PDFpdf draftv4.pdf r2 r1 manage 632.1 K 2018-10-11 - 10:08 DominikMueller  
PDFpdf draftv5.pdf r1 manage 632.8 K 2018-10-23 - 10:11 DominikMueller  
Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r10 - 2018-10-23 - DominikMueller
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback