ProjWData issues

I have some problems using ProjWData to fit a somewhat complex model for the decay time and invariant mass of a dimuon resonance.
[ul][]My signal time model is mostly the sum of a RooDecay convolved with a resolution gaussian with per-event errors, plus the same resolution gaussian to account for prompt decays. This signal time model is multiplied by a RooUniform prior for the per-event time error[/]
[]Same for the background, but using two RooDecays[/]
[]My signal mass model is a gaussian with per-event errors, while my background mass model is just a RooPolynomial of the first order. This mass model is multiplied by a RooUniform prior for the per-event mass error[/]
[]Mass and time models are put together in a RooAddPdf, to be fitted simultaneously[/]
Products with the two RooUniforms are made using RooProdPdf with Conditional; this should allow me not to use ConditionalObservables when fitting.

The fit to data works well, but when I plot I get something like


[#1] INFO:Plotting – RooAbsReal::plotOn(m2mu_t_model) plot on m2mu integrates over variables (t)
[#1] INFO:Plotting – RooAbsReal::plotOn(m2mu_t_model) plot on m2mu averages using data variables (m2mu_err,t_err)
[#0] ERROR:Eval – RooAbsReal::logEvalError(t_bkg_prompt_gauss_1_conv_exp(-@0/@1)t_t_bkg_nprompt_decay_tau_pos[t_bkg_nprompt_decay_pos]_Int[t]) evaluation error,
origin : RooRealIntegral::t_bkg_prompt_gauss_1_conv_exp(-@0/@1)t_t_bkg_nprompt_decay_tau_pos[t_bkg_nprompt_decay_pos]_Int[t][ Int t_bkg_prompt_gauss_1_conv_exp(-@0/@1)t_t_bkg_nprompt_decay_tau_pos[t_bkg_nprompt_decay_pos]dAna ]
message : function value is NAN
server values: !sumList=(), !intList=(), !anaList=(t = 150), !jacList=(), !facList=(), !func=t_bkg_prompt_gauss_1_conv_exp(-@0/@1)t_t_bkg_nprompt_decay_tau_pos[t_bkg_nprompt_decay_pos]=2.18826e-05/nan, !sumCat=()
[#0] ERROR:Eval – RooAbsReal::logEvalError(t_bkg_nprompt_decay_pos_Int[t]) evaluation error,
origin : RooRealIntegral::t_bkg_nprompt_decay_pos_Int[t][ Int t_bkg_nprompt_decay_posdAna ]
message : function value is NAN
server values: !sumList=(), !intList=(), !anaList=(t = 150), !jacList=(), !facList=(), !func=t_bkg_nprompt_decay_pos=2.18826e-05/nan, !sumCat=()
[#0] ERROR:Eval – RooAbsReal::logEvalError(t_bkg_nprompt_complexmodel) evaluation error,
origin : RooAddPdf::t_bkg_nprompt_complexmodel[ f_bkg_sym_asym * t_bkg_nprompt_decay_sym + [%] * t_bkg_nprompt_decay_pos ]
message : p.d.f value is Not-a-Number (nan), forcing value to zero
server values: !refCoefNorm=(), !pdfs=(t_bkg_nprompt_decay_sym = 0.000199328/17.831,t_bkg_nprompt_decay_pos = 2.18826e-05/nan), !coefficients=(f_bkg_sym_asym = 0.374464 +/- 0.0681783)
[#0] ERROR:Eval – RooAbsReal::logEvalError(t_bkg_nprompt) evaluation error,
origin : RooProdPdf::t_bkg_nprompt[ t_err_model * t_bkg_nprompt_complexmodel(t) ]
message : p.d.f value is Not-a-Number (nan), forcing value to zero
server values: !pdfs=(t_err_model = 1,t_bkg_nprompt_complexmodel = nan/1)
[#0] ERROR:Eval – RooAbsReal::logEvalError(t_bkg) evaluation error,
origin : RooAddPdf::t_bkg[ f_bkg_nprompt * t_bkg_nprompt + [%] * t_bkg_prompt ]
message : p.d.f value is Not-a-Number (nan), forcing value to zero
server values: !refCoefNorm=(), !pdfs=(t_bkg_nprompt = 0/1,t_bkg_prompt = 9.50547e-06/1), !coefficients=(f_bkg_nprompt = 0.290198 +/- 0.0404708)
[#0] ERROR:Eval – RooAbsReal::logEvalError(m2mu_t_model_bkg) evaluation error,
origin : RooProdPdf::m2mu_t_model_bkg[ m2mu_bkg * t_bkg ][/code]

and the plot obviously is not drawn. What can be the problem?

I have an additional question on ProjWData: is there any similar feature, to be used with createIntegral to compute, for example, the area of the per-event mass gaussian within a certain mass region?


The problem you see originates from the calculation of an analytical normalization integral of the term,
(relevant line of log file below)

origin : RooRealIntegral::t_bkg_nprompt_decay_pos_Int[t][ Int t_bkg_nprompt_decay_posdAna ]

One of the failure modes of this calculation is if the width of the Gaussian resolution goes to zero.
Does the range of your t_err observable start at exactly zero?

Concerning your second question: you can use createIntegral() to calculate integrals in any range
you like. It is a 2-step process

1) define a named range in your observable e.g.
    mass.setRange("A',-10,10) ;
  1. request an integral over that range, e.g.
    RooAbsReal* fracInt = pdf.createIntegral(mass,mass,“A”) ;

The latter form calculates the integral over mass (1st arg) of pdf while normalized over mass (2nd) arg
in in the range “A” (3rd) arg.

This technique has an equivalent in plotting as well. If you wish to project a straightforward range in one
of your projected observables, simply add


to your plotOn() command, which will restrict the projection integral to the given range. This technique
extends in a straightforward way to multiple dimensions (in either form) by simly defining ranges with
the same name in multiple observables.



thanks for the answer. The t_err observable range is: [0.01, 60] so the width of the gaussian resolution should never be zero. By the way this observable is also used for the signal RooDecay per-event error, which doesn’t give any problem.

Do you have other ideas on what this could be?

Thanks a lot,


perhaps it would be worth to mention that everything seems to work fine if we use a single RooDecay, instead of the sum of two RooDecay’s convolved with the same resolution gaussian… shouldn’t the analytical integral give problems/errors in both cases?

Hi Rene,

That seems odd indeed. If you send me a self-contained example that reproduces the problem I can investigate this in more detail.



I attach you here the example: you should find a small tree with the variables, the code is all contained in the .C file, and all of the headers are in the .h file.

You can run this as a root macro: root -l prova.C+

If you comment line 91 and uncomment line 92 you can see that the problem disappears: in this case you’re using a simple roodecay (and not the sum of two roodecays) for the background time model.

Thanks for your help,



sorry, I realized I had to modify the header file, otherwise the .C doesn’t compile…now you should be able to reproduce our problem.

Actually I am at cern, if you’re here too we could have a look at it together.