Ownership errors generating data from morphed PDFs

[zurowski]

Hi all,

Apologies in advance, but I’m a new member of the forum (but a long term lurker) and so cannot post links.

I am seeing an identical error to what was reported in the post titled “ERROR:InputArguments –RooArgSet::checkForDup…”

When running the rf616_morphing tutorial in ROOT v6.36.02 I see:

[#0] ERROR:InputArguments – RooArgSet::checkForDup: ERROR argument with name histpdf0_Int[x] is already in this set
[#0] ERROR:InputArguments – RooArgSet::checkForDup: ERROR argument with name histpdf1_Int[x] is already in this set
[#0] ERROR:InputArguments – RooArgSet::checkForDup: ERROR argument with name histpdf2_Int[x] is already in this set
[#0] ERROR:InputArguments – RooArgSet::checkForDup: ERROR argument with name histpdf3_Int[x] is already in this set
[#0] ERROR:InputArguments – RooArgSet::checkForDup: ERROR argument with name histpdf4_Int[x] is already in this set

In testing this tutorial (and running my own code) to investigate, it seems this is is triggered by various things:

• plotting the morphed PDF (once it has been read from the RooWorkspace)
• creating a NLL from the morphed PDF in the RooWorkspace
• plotting this created NLL
• generating data from a morphed PDF being read in from a RooWorkspace (this one isn’t in the tutorial but was something I tested separately)

These errors are also produced for every PDF that is part of the morphed object, so as you use more granular morphed PDFs these increase. Even though this is apparently an error that can be ignored, when you have many morphing PDFs, this slows so much that it is unable to generate data in a timely manner.

It seems that the commonality between all of these is:

• A morphed PDF is saved to a RooWorkspace
• It is then read directly from the RooWorkspace for some operation

Is there a workaround for this? Or even just an alternative way to generate data from a RooAbsPdf (which is my main use case).

Thanks in advance!

[zurowski]

Adding some additional info I have uncovered in my diagnostic attempts:

Understanding if it’s related to RooWorkspace

I tried directly generating data from the RooWrapperPdf object before saving it to a RooWorkspace and got the same error. So it seems to be related to the PDF object, not RooWorkspace I/O

Understanding if it’s something to do with RooWrapperPdf

I tested wrapping a non-morphed function (defined using bindFunction). This was able to generate data without error, so it seems the issue is related to either RooMomentMorphFuncND or its interactions with RooWrapperPdf

Adjusting the morphed object

I tried the same pipeline I had before (create a RooMomentMorphFuncND, use it to make a RooWrapperPdf, then try and plot it), but without calling “setPdfMode”. When I did this, I could generate data without the ownership related errors, but instead saw evaluation errors related to the slope used to calculate the morphing being infinite.

[#0] ERROR:Eval -- RooAbsReal::logEvalError(morph_func_BottomLid_82_210_Det12_offset_1_0) evaluation error, 
 origin       : RooFormulaVar::morph_func_BottomLid_82_210_Det12_offset_1_0[ actualVars=(pdf_res1_BottomLid_82_210_Det12_MOMENT_1_Eobs,morph_func_BottomLid_82_210_Det12_pos_0,morph_func_BottomLid_82_210_Det12_slope_1_0) formula="x[0]-(x[1]*x[2])" ]
 message      : function value is NAN
 server values: actualVars=(pdf_res1_BottomLid_82_210_Det12_MOMENT_1_Eobs = 1.52274e+06,morph_func_BottomLid_82_210_Det12_pos_0 = 0,morph_func_BottomLid_82_210_Det12_slope_1_0 = inf)

I’ve seen this error before when playing with morphed objects, and tracked it down to the fractional coefficients being set to zero. Sure enough, looking at the RooFit source code (RooMomentMorphFuncND_8cxx_source.html), if you call setPdfMode() then this sets the initial values to 1 instead of 0, which explains why this error has appeared when I don’t call that.

What I don’t understand is why the ownership error appears when _isPdfMode is set to true (which is, as far as I can see, the only thing this call does). The only other place I see this parameter causing a difference is by using RooAddPdf instead of RooRealSumFunc. Do the two have different automatic ownership over their construction components, which might mean that when you call RooAddPdf then add the owned components you are trying to add components that are already owned by the theSum object?

[jonas]

Thank you for spotting this! I have opened a fix:

[RF] Don't warn about duplicates in temporary RooArgSet in RealIntegral