RooFit convolution + constraints Likelihood fit

Hi,

  1. it seems that to fix the numeric convolution fits it is enough to change the setConvolutionWindow() parameter so that they correspond
    to the ones used by the resolution function:
    // PDFxG.setConvolutionWindow(m, s, 5);
    PDFxG.setConvolutionWindow(mean_FFT, sigma_FFT, 5);
  1. regarding the problematic FFT convolution with internally-constrained fit, I’ve ran into a similar issue recently, and AFAIU it occurs due some numerical problems
    related to the fact that the FFT convolution returns scaled pdf, with ‘raw’ (un-normalized) values easily reaching the range 10^8-10^12 or higher
    (the order of magnitude strongly depends on the binning in x).
    (This PDF scaling is mentioned in a comment in the FFT tutorial https://root.cern/doc/master/FFT_8C.html
    and also in the FAQ of the underlying FFTW library http://www.fftw.org/faq/section3.html#whyscaled ).

In my case the fits of convoluted PDF with internal constraints were very unstable, while fits of the same PDF with external constraints behaved well.
As far as I could trace it down, there exists some difference at least in the order of calculation of the log-likelihood
between the externally-constrained and internally-constrained fits. In case of the external constraints,
the logarithm of the PDF and the logs of the constraint terms are calculated separately and then their sum is maximized.
Whereas in case of using internal constraints, the log is taken of the total RooProdPdf containing both the signal PDF and the constraint terms.
Normally RooFit automagically normalizes the PDFs when it decides to do so.
Possibly (but here I’m not at all sure - one might have to study the dependency tree of the resulting RooProdPdf) in case of the
internal constraints the automatic normalization of the PDFs is done after the multiplication of the signal pdf term by the constraints,
and that somehow leads to loss of precision.

My solution for this problem was to introduce a compiled ‘proxy’ pdf which just returns the normalized convoluted signal PFD, e.g.:

RooAbsPdf *PDFxG_norm = RooClassFactory::makePdfInstance("qq", "PDFxG.arg().getVal( RooArgSet( x.arg() ) )", RooArgSet(PDFxG, x), "x:1");

rf604_constraints_fft_norm.C (5.4 KB)
See the attached script.
( I’m using v6.20.02 ROOT version - in the newer versions the syntax may not require calling varname.arg() to access getVal(). )

By the way, apparently, similar problem has been reported earlier in the following thread:
https://root-forum.cern.ch/t/problem-using-convolution-with-roofftconvpdf/21517/2

1 Like