I’m trying to fit a sum of two exponential decays convoluted with a gaussian resolution function (with a constant background). RooFit allows us to do it with two approaches:
- A sum of RooDecays convoluted with RooGauss Model provides reasonable value for fraction of exponents (compared with other fitting software on the market).
- A sum of custom exponential decays inherited from RooAbsPdf convoluted with RooFFTConvPdf gives notably different fraction coefficient value.
Unfortunately due to complexity of our other fitting models we need to use second approach with custom RooAbsPdf’s. Is there a way to get RooFFTConvPdf to give correct RooAddPdf coefficient values for exponential decays? Different fit options, buffer strategies and fft binning options do not seem to help here.
Attached please find the root script “convtest.c” and canvas render displaying the discrepancy between fraction coefficients.Script tested with RooFit v3.60 and Root 6.14/02 on MacOS 10.13.3.
P.S.: I’ve posted this issue earlier before here on the forum and reported in Jira too. I present some data at a conference later this August and looking forward to hearing from you.
Thanks in advance,
convtest.zip (10.4 KB)
I guess @moneta can help you.
Hi Olivier, thanks for your reply. I messaged @moneta but never got a reply. Will text him again now!
Yes, Lorenzo is really the expert in that area.
I am not sure, looking at the code, that the meaning of the coefficient is exactly the same in the two cases.
I would check this carefully, writing down the equation in both cases
Hi Lorenzo! Thank you for your answer. Here I attach a PDF file to this message explaining the discrepancies of models used in every approach.
First approach sums two exponential decays independently convoluted with gauss (by means of RooDecay). So we convolute first, then sum.
Second approach convolutes a sum of two exponents with same lifetimes with a gauss (by means of RooConvPdf). Here we sum first, then convolute.
Last but not least - we add a constant background with constant contribution just for better fit of the experimental spectrum.
Looking forward to hearing from you. Let me know if you have any questions with respect to the code.
approaches.pdf (110.2 KB)
Thank you for your notes. I will look at this in detail
I had the same problem. What if instead of doing the convolution with the sum of PDFs, you do the convolution with each PDF and THEN add them?
Hi! That’s exactly what I was planning to test. The linearity property of RooFTTConvPdf. Will check it later today.
Indeed, RooFFTConvPdf gives incorrect pdf’s coefficient values for convolution of a sum of pdf’s (via RooAddPdf). @Angel_Campoverde provided the correct workaround to this RooFit issue. One has to FIRST convolute each of pdf’s individually and THEN sum them with RooAddPdf.
From the mathematical point of view this behavior is a bug. I would like to draw developers’ attention here. Will prepare a snippet of code that reveals the problem later today.
I agree this is a bug. It would be great if you can submit a JIRA bug for this so it will be tracked and hopefully fixed one day. This is the link to submit a bug report:
Independently of this, have you tried using RooNumConvPdf ? Did you observe the same bug in this case
Hi Lorenzo! Thanks for your reply. I posted an issue in JIRA and attached a sample code that demonstrates the problem. I consider the issue quite critical. Hope it will be resolved soon.
Yes, I did test RooNumConvPdf as well. It turns out to have a similar problem.
P.S: Earlier this May I’ve posted another JIRA story that was a precursor to the current one. I interlinked these issues in JIRA.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.