Bug? Range() command enforces numerical integral

[LbtLoic]

Dear RooFiters,

I came across an undesired behaviour from RooFit when I create a negative log-likelihood with the RooFit::Range() command RooFit uses numerical integration:

RooAbsReal* nll =(RooAbsReal*) model_2D_ProjY->createNLL(*y_Data,RooFit::Verbose(),RooFit::Optimize(kTRUE),RooFit::Range("R"));

I get as output:

[#1] INFO:Eval -- RooRealVar::setRange(y) new range named 'R' created with bounds [0,10]
[#1] INFO:Fitting -- RooAbsOptTestStatistic::ctor(nll_model_2D_Proj[x]_genData) constructing test statistic for sub-range named R
[#1] INFO:Eval -- RooRealVar::setRange(y) new range named 'NormalizationRangeForR' created with bounds [0,10]
[#1] INFO:Eval -- RooRealVar::setRange(y) new range named 'fit_nll_model_2D_Proj[x]_genData' created with bounds [0,10]
[#1] INFO:Fitting -- RooAbsOptTestStatistic::ctor(nll_model_2D_Proj[x]_genData) fixing interpretation of coefficients of any RooAddPdf to full domain of observables 
[#1] INFO:NumericIntegration -- RooRealIntegral::init([model_x_X_ratio(model_y_Int[y],model_y_Int[y|NormalizationRangeForR])]_Norm[x]_denominator_Int[x]) using numeric integrator RooIntegrator1D to calculate Int(x)
[#1] INFO:NumericIntegration -- RooRealIntegral::init([model_x_X_ratio(model_y_Int[y],model_y_Int[y|NormalizationRangeForR])]_Int[x]) using numeric integrator RooIntegrator1D to calculate Int(x)
[#1] INFO:NumericIntegration -- RooRealIntegral::init([model_x_X_ratio(model_y_Int[y],model_y_Int[y|NormalizationRangeForR])]_Norm[x]_denominator_Int[x]) using numeric integrator RooIntegrator1D to calculate Int(x)
[#1] INFO:NumericIntegration -- RooRealIntegral::init([[model_x_X_ratio(model_y_Int[y],model_y_Int[y|NormalizationRangeForR])]_Norm[x]_X_model_y_NORM[y]]_Int[x]) using numeric integrator RooIntegrator1D to calculate Int(x)

It resorts to numerical integration even if the Range is the same as the natural range of the variable.
Is there any way to prevent RooFit to use numerical integration when it is not necessary ?

I join a simplified macro reproducing the issue Projected2D_Simple.C (1.9 KB) (I run it on ROOT Version: 6.18/04)
but the real model I’m working on is much more complex and numerical integration is becoming an issue because of computing time.

If anyone could look into that, I’d be grateful.

Cheers,
Loïc,

[oshadura]

@moneta can you please take a look? Thanks!

[LbtLoic]

I imagine everyone is quite busy at the moment, still I would be glad if someone could take a look and help me come up with a solution or a workaround.

Regards,
Loïc,

[eguiraud]

Ping @moneta

[moneta]

Hi,
RooFit needs to compute the normalisation of the PDF so it needs to compute their integrals. The range only defines the limit of the integrals.
Some PDF (e.g. gaussian) implement the analytical integral when the pdf is normalised in x (typical case for a Gaussian).
In your case , the model is quite complex, mean and sigma of the gaussian depends on x, so the integral is not anymore trivial, and RooFit is not able to compute it analytically.
I understand this is an issue, but the only solution is to implement yourself the pdf and provides the integral, if it can be computed analytically in this case.

Cheers

Lorenzo

[LbtLoic]

Thank you Lorenzo for your answer.
My main problem is that when I used the Range command when I define the likelihood function, RooFit ignores the analytical integral that is provided. If I remove the Range command from the likelihood it is able to perform an analytical integral (at least partially). So I assume that it should be able to do it even if a Range is required.

I don’t get why the Range command induces a difference in RooFit integration behaviour.

Cheers,
Loïc,

[moneta]

Hi,
I understand the problem now and I could reproduce using your example. Probably an issue with the RooProdPdf normalisation calculation. I will investigate and eventually open a GitHub issue

Lorenzo

[moneta]

Hi,
I found a problem in the computation of the partial integrals of the conditional RooProdPdf when the reference range is equal to the normalisation range. In this case, you should not need an extra integral that is instead request. See code around RooProdPdf.cxx:857 (ROOT: roofit/roofitcore/src/RooProdPdf.cxx Source File).
I will produce a PR for this.

However when the Range is set different than the variable reference range, I suspect this integral is needed and you cannot avoid this multiple integration that will slow enormously the pdf evaluation.

Lorenzo