-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[RF] RooAddPdf fails if pdfs have the same name #8000
Description
- [V] Checked for duplicates
Describe the bug
RooAddPdf, if initialized with pdfs with the same name, is evaluated wrongly. It interprets all pdfs with the same name as the first of them (function and parameters are the same for all pdfs, while the coefficient is the proper one, as should be if that pdf was the corresponding pdf).
Expected behavior
- pdfs must be operated as different C++ objects/pointers, not based on name. Otherwise
- pdfs with the same name must be forbidden. RooAddPdf must fail to initialize if some pdfs have the same name. RooAddPdf class description should specify that pdfs with the same name are not allowed.
To Reproduce
I make a 3-dimensional parametric fit of the detector. I model its parts as cylinders, and there are many of them, so I simply copied some common initialization code. The reused pdfs were not simply summed in RooAddPdf, but they were inside RooProdPdf-s (those had distinct names).
Pdfs were different C++ objects and had different parameters. For different types of pdfs all converged well, but when I used 2 same pdfs (with the same name, but in absolutely different regions), the fit did not converge, and the plot was wrong.
When I plotted (separate pdf or with RooFit::Component of the total sum), it showed that one pdf got parameters of another pdf (even though it was outside its allowed range), though its normalization was as it should probably be. The total sum (the pdf I fitted) was also plotted wrongly.
I used RooAddPdf constructor with RooArgList PdfList and RooArgList CoefList, if that is important.
I think the easiest would be to create a new example from scratch. I can copy some code here if needed.
Setup
- ROOT version 6.22/06.
- Arch Linux.
- Built it myself.