Hi all,
I’m attempting a fairly complicated full angular fit. I have a single signal PDF which has 24 parameters and 4 observables. I have implemented the integral over these observables. I then have a background PDF which is a RooProdPdf of 3 RooChebyshevs, a RooGaussian, a RooBreitWigner and a custom PDF (again 24 parameters, only one observable) which also has the analytic integral implemented. If I use either signal or background PDF to make projections over the observables or fit everything is fine.
I combine these two using a RooAddPdf with a signal fraction (i.e. not extended mode). When I run my fit, after some amount of fitting I get the error message from the subject of this post. It seems to be coming indirectly from the RooMCIntegrator.
Does anyone have any idea what may be happening here and if I can do anything to stop it? One option I was considering was creating another background PDF where I again did the integration myself using, most probably, the GSL. Would this help? I’m using Root 5.18.00a.
Thanks in advance for any ideas.
Cheers!
Will
It seems that it is not only the background PDF which produces this error after all (although it makes is occur much sooner). If I only use the signal PDF (25 parameters, 4 observables) and refit it many (17) times with different starting values then I get the same error. This is a problem as the fit does’t fail, it just fills up the log file with GBs of the same error message. Am I right to think that the MC integration is failing for some corners of parameter space? Currently I implement the integral over all and three of the observables. Would implementing more of these integrals over different sets of observalbes help?
Cheers!
Will
Hi Will,
(Sorry for the late reply, I was on vacation for a while among others)
I’ve personally never seen this error message, so it appears something unusual is going on. If you implement analytical integrals over all observables that should normally be picked up by RooFIt and no MC integrations should be called. I think that is the
part that needs to be understood first.
To do so it is most instructive to create an integral over your p.d.f by hand
RooAbsPdf* myPdf ;
RooAbsReal* myPdfNormInt = myPdf->createIntegral(RooArgSet(observables)) ;
If you then do a myPdfNormInt->Print(“v”) you can see how the final integral is constructed in terms of analytical and numeric components. If you are using a recent version of ROOT/RooFit (ROOT >=5.18) you can also learn more about the logic that is used to arrive at the integrator configuration by prepending the following statement to
the above example
RooMsgService::instance().addStream(RooMsgService::INFO,Topic(RooMsgService::Integration)) ;
Once this is made to work correctly you should be reduced (hopefully) to fully analytical
integrals or numeric integration in at most one dimension, which is a much more tractable problem than multi-dimensional numeric integration (GSL will not be of much use for that either).
Wouter
Hi Wouter,
No problem. Thanks for the tips, I’ll investigate more and get back to you.
Even if its not clear why the RooMCIntegratior is being used, I think the current “keep going” behaviour is undisirable. The problem is that once the RooMCIntegrator gets into the error state it just keeps printing the error message for ever (or until its killed) in a tight loop. This in turn produces huge log files which have made sys admins at certain grid sites unhappy… Would it be possible to detect that the RooQuasiRandomGenerator has hit an error state and then bail out of the integration or even the fit?
Cheers!
Will
Hi Will,
That should definitely be possible. I’ll look into a fix for this for the upcoming 5.20 ROOT release.
Wouter
Hi Wouter,
Thats great. Thanks for the help.
Cheers!
Will