Difference between root 6.18 and 6.22 for RooProdPdf

Dear all,
I have two scripts (Priors_with_bkg.C , Priors.C ) which I join here that both give different results between root 6.18/04 and 6.22/02. You can run them like this:

root [0] .L <macro_name.C>
root [1] <macro_name()>

For the former version the result is as expected:
Poisson_posterior_for_5_nobs_and_0_b_618.pdf (15.8 KB)
While for the more recent version the RooProdPdf “jefPrior_posterior” seems to be zero everywhere:
Poisson_posterior_for_5_nobs_and_0_b_622.pdf (15.3 KB)

This difference in behaviour seems independent of the values of the parameters.

Any help will be greatly appreciated.

Best regards,
Marco Bomben

Hi @bomben! I think there were a lot of changes between 6.18 and 6.22 done by @StephanH (https://root.cern/doc/v620/release-notes.html#roofit-libraries and https://root.cern/doc/v622/release-notes.html#roofit-libraries).

I hope @StephanH maybe can clarify or @moneta will take a look. Thank you in advance!

cc: @Axel

Hi,
I can indeed reproduce the problem. I have created a GitHub issue

Thank you for reporting this problem

Lorenzo

Actually the problem seems to be in computing the function integral for the normalisation.
Adding this line (but requires to have ROOT built with math more support) fixes the problem:

RooAbsReal::defaultIntegratorConfig()->method1D().setLabel("RooAdaptiveGaussKronrodIntegrator1D");

Lorenzo

Thank you so much @moneta! Now it works, in 6.18 too.

Regards,
Marco Bomben

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

I think it’s the correct behavior that this code doesn’t work in newer ROOT versions.

You define this prior here:

// Jeffreys prior
RooGenericPdf jefPrior("jefPrior","Jeffreys prior","1.0/sqrt(s)",RooArgList(s));

and your variable s is defined from zero to nobs*3+5:

// number of expected events
RooRealVar s("s","s",1,0,nobs*3+5);

So you get a division by zero in your range, and were just lucky that it worked out somehow in ROOT 6.18.

The best fix to this problem is to increase the lower limit of s to a small positive value like 0.01.