---
# System prepended metadata

title: Untitled

---

## Comments from Referees over Belle Note 

### William

+ [ ] is my impression correct that the analysis is far enough along that setting up a **blinding analysis** as suggested below would be difficult (or at least involve a fair amount of backtracking)?
    > 最好潤一下
    > Thanks for pointing this issue out. It is very important to make sure the measurement is not biased. 
    > We are not sure whether this could still be taken as the blinding analysis to some extend, though we have already checked the final measurement on data. 
    > The analysis strategy is the same as the published study on ALEPH open data, other than some fine corrections to get reduce systematics (as described in Sec 4.3,4.4). So at least we can ensure that the strategy is not biased. 
+ [ ] what are the **status, plans and timeline** for the completion of the sections 7 and 8, e.g., (**thrust frame**) analysis and associated BN writeup.
    > In the final publishment, we plan to include thrust analysis, event generator study. And now we are trying to finalize the thrust analysis part. There are still some aspects we do not fully understand. We are investigating and will report the result a.s.a.p. .
    > We also hope to present in ICHEP 2020, which is held on late July, early August. But we just notice that the deadline for the abstract submission is close from now (on 2/15). We are very sorry to raise the issue up and make the bold request that we'd like to ask for your permission for our submission on ICHEP. And we  attatched the draft of our abstract in this letter.
    > About the details of the timeline we hope to finish thrust analysis by the end of March (estimated conservatively, I think we don't need such long time), and spend another two more months for the generator analysis (this part might left optional for the conference, dep. on the progress). As for the documentation, we would carry it out in the meanwhile. We shall have sufficient time to fulfill it. Apologize again and hope you can consider our request. Thanks!
    > 
**TODO: check with Paoti when will be a good time to report in a conference**

+ [x] it will be helpful during the refereeing process to have:
    1. **line numbers** attached to the text. 
        > Line number feature is completed by CW.
        > Note: need to decide whether line number should restart numbering in each page/chapter, i.e. 
    ![](https://i.imgur.com/p5If7TG.png =x300)   or    ![](https://i.imgur.com/2EGk0jv.png =x300)

    2. As well, for future changes a **"change log" section** 
        > A change log section now has been added at the bottom of the note.
        > Move this section into appendix will be better.
    3. **ability to produce "diff" .pdf files** 
(e.g., highlight what is changed in an original/previous version compared to an updated one) will be useful.
        > + versioning on Overleaf: TwoParticleCorrelationAtBelle.tex > History > Labels. (now a bn1532_v2.2 labels is created.)
        > + can use: `latexdiff new.tex old.tex > diff.tex` to create a diff.pdf 
        > + comment: can you change the highlighted color to other color instead blue? It looks not so obvious, also the [PENDING] marks are also blue one. I think if it is possible use pink or yellow background color to highlight it is the best option.


### Ralf
+ [x] Could you use the linenumber package in order to give comments more easily?
+ [x] I am looking to see also the **thrust frame analysis**. I am not quite sure what you mean with that, though. You should always be in the c.m. **Or are you planning to look with respect to the thrust axis?** 
    > 1. Yes, we are always in the CM frame, but 2 analyses (beam, thrust) will take different reference axes to coordinate the particles.
    > 2. Sorry that it is misleading that we use the term "Thrust/Beam frame". Now we change to "Thrust/Beam axis".
    > 
    > (Maybe we should change the name "Thrust/Beam frame" to the correct one "Thrust/Beam axis" in all case?)
    > 
    Looking at correlations for **different thrust values** certainly would be interesting.
    > Same comments as 6.

### Introduction
+ [ ] Could you specify what **hadronization model Herwig used**? 
    > (I think he is asking about the ALEPH research? or else we haven't mentioned we use Herwig to model.)
    > 
    In my Belle fragmentation analyses I found that **the Pythia default tune (I used 6.4, but 8 seemed to be also ok)** describes various hadron cross sections quite reliably, but the **Pythia tune used in the Belle generic MC is not optimal.**
    > We now current use MC generated by BELLE MC group, which is hadronized by Pythia 6.205. And we hope to try on different hadronization models in the following research.
    > 
**TODO: check with BELLE MC experts**

+ [x] I also wonder if it might be interesting to test how your results change:
    when **switching off initial state and final state radiation**. 
    (ISR can change the actual boost of the qqbar system which could have in impact on your correlations.)
    > OK, we can give it a try with PYTHIA. 
    > 
**TODO: can give it a try with PYTHIA**


### Sample
+ [x] It is common to also put cuts on the **total visible energy to reduce the tautau contribution.**
    > For the event selection, we haven't optimized by ourselves but use HadronBJ skim (with $E_{vis} > 0.2 \sqrt{s}$).

+ [x] The luminosities you quote seem to be incorrect: 
The whole SVD2 sample (which starts with experiment 31) should be about 558 fb -1 on-resonance and also substantially larger than the 31 you quote for continuum. 
Could you check where you got your numbers from? They are usually tabulated at the end of your basf output.
    > The luminosity we quoted is correct. The reason that there is a huge difference between the two is that we only use very few part of the whole SVD2 data(in order to match all QED MC runs)

+ [x] How do you deal with **particle id**? 
In order to correctly boost back to the c.m., you need to take the particle masses into account. 
The nominal pid following the default procedures (see for example my recent BNs) is not perfect but it may be sufficient for your purposes.
    > We also use the muon-hadron, electron-hadron, kaon-pion, kaon-proton, and pion-proton likelihoods to identify different charged tracks. But our selection criteria are different. To be comprehensive, we list out here:
    >
    > 1. $\mu^{\pm}$ are identified with $\mathcal{L}_{\mu} > 0.95$ and $\chi^2 > 0$ and should not be prerejected ($\texttt{!muon.Prerejection()}$). 
    > 2. e$^{\pm}$ with $\mathcal{L}_{\rm e} > 0.9$
    > 3. P$^{\pm}$ with $\mathcal{L}_{\text{K/}\pi} < 0.1$, $\mathcal{L}_{\text{P/}\pi} > 0.9$
    > 4. K$^{\pm}$ with $\mathcal{L}_{\text{K/}\pi} > 0.25$. 
    > 5. the rest are $\pi^{\pm}$. 

### Methodology

> Sorry that we might not be that clear, so We've rewrite the description for Eq(1). 
> The correlation function, defined as the LHS of Eq(1), is a 2D distribution, which records spatially per-trigger-particle associated yields (track pairs) over $(\Delta \eta, \Delta \phi)$ plane, in the unit of event. In Eq(1), $N^{\rm pair}$ counts the amount of track pair combinations, and $N_{\rm trig}$ counts the amount of trigger particles. And  precisely speaking, a single event can give this track pairs' correlation distribution. To get rid of the impact of statistical fluctuation, the final correlation function being analysed on is the average of all events' correlation function. 
+ [x] When you talk about building combinations with trigger particles, does that mean you **consider all combinations of two charged particles that pass high quality requirement?** 
I assume you make sure that you do **not double-count the pairs**, right?
    > Yes, $N^{\rm pair}$ counts the amount of  combinations in one event.

+ [x] In equation 1, do you not bias yourself to high multiplicity events (within your multiplicity bin) by only **normalizing with N_trig, while there are about N_trig factorial combinations**?
    \begin{equation}
    \frac{1}{N_{\rm trig}}\frac{\rm d^2N^{pair}}{\rm d\Delta\eta d\Delta\phi}= B(0,0) \times \frac{S(\Delta\eta, \Delta\phi)}{B(\Delta\eta, \Delta\phi)},
    \end{equation}
    > The normalization with $N_{\rm trig}$ is to get averagelly the amount of track pairs the trigger particle would be matched to.

+ [x] I do not understand your classification into **signal and background** here. 
In e+e- **pileup, MPI**, etc do not play a role so you should not have any underlying background. Is this B then unity?
    > As you suggest we do not expect underlying events in Belle data set. The background function, also be expressed in a 2D distribution (as fig.2 shows), represents purely the correlation over uncorrelated and random events. We use this to factor out the random combination correlation in the signal function, and then their ratio could objectively shows the physical particle correlation.
    > (In some sense, maybe we can say it is unity for this particle correlation representation under certain event topology. That is, if S shapes exactlly like B, we get flat correlation.)

### Corrections
> Rewrite the descriptions of extrapolation.
> The correlation functions, expressed as \"density functions\": $d^2N/\text{(bin width)}^2$, should be independent of the bin width ideally. However, in practice, they are represented using the discrete histograms, so they can only closely approach to but never become the true continuous functions. And this will bring in some bin width dependency to the observed correlation function value, so for the function value in the origin $B(0,0)$, which is used for scaling in Eq(3). 

+ [x] following up on me not understand these B functions, I am not quite sure what you are studing here for **B(0,0)**. You mention, that only in one dimension there is a bin width dependence, **but it would be good to see the other dimension as well**
    > We have added a figure (fig 7) for comprehensive information.
    > 
    Could you explain why there is **such a peak in the MC**? Should I be worried, that the values are different between Figs. 6/7 and 8 (now Figs. 8/9 and 10)?
    > 1. Sorry for the inconsistency btw Fig. 9 & 10, that is a mistake of pasting wrong file, and thanks for your pointing out, now it is fixed. Figure 8 & 9 shows the final B(0,0) as a function of bin width after the veto of tiny |∆η|,|∆φ| window (7e-3). Figure 10 shows the curve without this operation.
    > 2. We have done some research on this and conclude that the spike occurs because some of the beam background in the Belle MC are reused over different events. Hence, when calculating those track pairs correlation, the duplicated tracks will contribute in exactly (|∆η|,|∆φ|)=(0,0). 
        And since the correlation function is expressed as a "density function", i.e. $d^2N/\text{(bin width)}^2$, the non-vanishing amount squeezed in (|∆η|,|∆φ|)=(0,0) will make $d^2N/\text{(bin width)}^2$ ever-shooting when (bin width) gets close to 0.
        > (our previous discussion: [here](https://hep1.phys.ntu.edu.tw/~janicechen/CheckB00/OriginInvestigation.html))

### Results
+ [x] These results appear to look reasonable as far as I can tell. It would be interesting to see, how they change when selecting **different event topologies via the thrust value**:
A high thrust contains mostly two-jet events ( and hardly any B decays) while at low thrust you can get more 3-jet events and the B decays.
    > Yes, we agree, this is an interesting point to see. We have studied this in the thrust-axis analysis, and we could make a thorough research (also for beam-axis) and document it.
+ [ ] The **statistical uncertainty evaluation** is not quite clear to me and I do not quite understand where the harmonics come in. Also, following this up, how do you then **quantify that you do not observe a ridge signal**? Maybe this just needs to be better explained to non HI people?
    > [tmp] From the long range $Y(\Delta \phi)$ in fig. 17, 18, or a zoom-in associated yield distrution (focus on $0 \le \Delta \phi \le 1.5$), we could hardly see a ridge signal. 
    > + need a plot for illustration, and also in the current version the description/definition of ridge signal is vague.
    > 
    > Since the measurement is too close to 0, we decide to report the 95% UL. We use bootstrapping method, where both systematic and statistical uncertainties are incorporated, to obtain the upper limit.
    > The fourier harmonics is regarded as a good candidate to depict the flow-like particle correlation reflected in the azimuthal differential yield (could also have non-flow component). Hence, we use it (also with other functions) to fit. From the fit (evaluation):
    > 1. We get $c_{zyam}$ for the ZYAM-substraction. 
    > 2. Based on the fit, we do some modulation proportional to the uncertainties to obtain the ridge yield distributions. (fig. 26, 27)
+ [x] I guess Fig 26 is then your main result, together with the correlation functions from Fig 13 - 16, right?
    > Yes

---
## mail draft

Dear referees,

Thanks for all your comments and sorry for replying so late. We just pass through Chinese new year holiday in the end of January.

First of all, as your suggestion, we add line number and change log section(in appendix part) to our BN, also a "diff.pdf" is generated. Both files are now uploaded to BN page.

For the concern about blinding analysis, thanks for pointing this issue out. It is very important to make sure the measurement is not biased. 
We are not sure whether this could still be taken as the blinding analysis to some extend, though we have already checked the final measurement on data. 
The analysis strategy is the same as the published study on ALEPH open data, other than some fine corrections to get reduce systematics (as described in Sec 4.3,4.4). So at least we can ensure that the strategy is not biased.

About what we called "thrust frame analysis,"" we are sorry that it is misleading that we use the term “Thrust/Beam frame analysis”. We are always in the CM frame. Now we change it to "Thrust/Beam axis analysis". 

1. Introduction
We now current use MC generated by BELLE MC group, which is hadronized by Pythia 6.205. And we hope to try on different hadronization models in the following research.
We also would like to try switching off initial state and final state radiation by Pythia afterward.

2. Sample
total visible energy cut:
We haven’t optimized by ourselves but only use HadronBJ skim (with E_vis>0.2√s).
luminosity:
The luminosity we quoted is correct and it comes from basf output. The reason that there is a huge difference between the two is that we only use very few part of the whole SVD2 data(serveral hundred runs for each exp), in order to match all QED MC runs.
particle id:
We also use the muon-hadron, electron-hadron, kaon-pion, kaon-proton, and pion-proton likelihoods to identify different charged tracks. But our selection criteria are different. To be comprehensive, we list out here:
(1) μ± are identified with L_μ>0.95 and χ^2>0 and should not be prerejected (!muon.Prerejection()).
(2) e± with L_e>0.9
(3) p± with L_K/π<0.1, L_p/π>0.9
(4) K± with L_K/π>0.25
(5) the rest are π±

3. Methodology
Sorry that this part might not be that clear, so we’ve added some description at line 118. N^pair counts the amount of combinations in one event with both particles pass all requirements, of course double-counting situation is well treated. N_trig counts the amount of triger particles in one event. We have to emphasize that here the associated yield is calculated within one event. The final signal and background correlation functions will be summing up the associated yields from all events then normalized by number of events, respectively.
As you suggest we do not expect underlying events in Belle data set. The background function, also be expressed in a 2D distribution (as fig.2 shows), represents purely the correlation over uncorrelated and random events. We use this to factor out the random combination correlation in the signal function, and then their ratio could objectively shows the physical particle correlation.
(In some sense, maybe we can say it is unity for this particle correlation representation under certain event topology. That is, if S shapes exactlly like B, we get flat correlation.)

4. Corrections
About the reason why we study for B(0,0), please check the description that we have rewritten in line 191: The correlation functions, expressed as “density functions”: d^2 N/(bin width)^2, should be independent of the bin width ideally. However, in practice, they are represented using the discrete histograms, so they can only closely approach to but never become the true continuous functions. And this will bring in some bin width dependency to the observed correlation function value, also to the function value in the origin B(0,0), which is used for scaling in Eq(1).
For the other dimension of bin width dependency that we did not study, we have added a figure (fig 7) for comprehensive information.
Figs. 6/7 and 8 (now Figs. 8/9 and 10):
Sorry for the inconsistency btw Fig. 9 & 10, that is a mistake of pasting wrong file, and thanks for your pointing out, now it is fixed. Figure 8 & 9 shows the final B(0,0) as a function of bin width after the veto of tiny |∆η|,|∆φ| window (7e-3). Figure 10 shows the curve without this operation.
We have done some research on this and conclude that the spike occurs because some of the beam background in the Belle MC are reused over different events. Hence, when calculating those track pairs correlation, the duplicated tracks will contribute in exactly (|∆η|,|∆φ|)=(0,0).
And since the correlation function is expressed as d^2 N/(bin width)^2, the non-vanishing amount squeezed in (|∆η|,|∆φ|)=(0,0) will make it ever-shooting when (bin width) gets close to 0.

5. Results
different event thrust value analysis:
Yes, we agree, this is an interesting point to see. Actually we have studied this in the thrust-axis analysis, and we could make a thorough research (also for beam-axis) and document it.
the statistical uncertainty evaluation:
We are sorry for the unclearness of this part. Sec 6.3 is not aim on evaluating statistical uncertaincy, but to take statistical uncertainty into consideration and proceed to get the ridge yield. Hence we have changed the subsection title, also some description.
In this section, ZYAM method is used for getting ridge yield, which accounts for the significance of ridge signal. The three functions are referenced from citation 18, another two-particle correlation analysis also for e+e-. Beside this, the most important thing is the three function should be able to describe our associated yield distribution well.
About how to quantify that there is no ridge signal, we did not see a certain criterion on the value of ridge yield claiming this over other studies, but we think this is really an important issue. At this time we can compare our result with those studies that observed ridge signal. In 7TeV pp collisions(https://arxiv.org/pdf/1009.4122.pdf), their yield lies on about 1e-2 order(Fig9,10), while our mean value of bootstrapping result not over 1e-5 order. However, we still have to say that the simple comparison of the yield between the two different collision and different multiplicities may be not fair.
main result:
Yes, that is correct.

And finally, for the stauts ,plans and timeline:
In the final publishment, we plan to include thrust analysis, event generator study. And now we are trying to finalize the thrust analysis part. There are still some aspects we do not fully understand. We are investigating and will report the result a.s.a.p. .
We also hope to present in ICHEP 2020, which is held on late July, early August. But we just notice that the deadline for the abstract submission is close from now (on 2/15). We are very sorry to raise the issue up and make the bold request that we’d like to ask for your permission for our submission on ICHEP. The draft of our abstract is here().
About the details of the timeline we hope to finish thrust analysis by the end of March (estimated conservatively, I think we don’t need such long time), and spend another two more months for the generator analysis (this part might left optional for the conference, dep. on the progress). As for the documentation, we would carry it out in the meanwhile. We shall have sufficient time to fulfill it. Apologize again and hope you can consider our request. Thanks!

By the way, it seems that the document list on the indico page is not assigned to us yet, so we can not use it to upload files. How can we get access to it?

Best Regards,

Yu-Chen and Cheng-Wei