I am trying to build a RooAbsPdf in the following way:
TF2 *funcTF2 = new TF2("funcTF2", polXY, xMin, xMax, zMin, zMax, nPar);
RooAbsPdf* squareDalitz = RooFit::bindPdf(finalTF2, x,z) ;
RooAbsPdf* finalPdf = new sqDalitzToMassesPdf("sqDalitzToMassesPdf","sqDalitzToMassesPdf", x, y, squareDalitz, &z);
where “sqDalitzToMassesPdf” is a class autogenerated by RooClassFactory whose evaluate is:
Double_t sqDalitzToMassesPdf::evaluate() const
// ENTER EXPRESSION IN TERMS OF VARIABLE ARGUMENTS HERE
z->setVal( f(x, y) );
return squareDalitz->getVal() ;
My code works fine until I ask for the “createHistogram” method on “finalPdf” and it gives the attached stack trace.
The reason for this code structure is that I am only able to fit the (x,z) distribution with a TF2, but I need a RooAbsPdf as a function of the (x,y) variables.
Stack_trace.pdf (43.6 KB)
Likely either z or squareDalitz is a null pointer. Maybe simply add printf("z=%p squareDalitz=%p, z, squareDalitz); as the first line of sqDalitzToMassesPdf::evaluate() to see which one? Then you’ll need to find out why it’s null.
I will ask Lorenzo for help, too - maybe it’s something obvious in RooFit’s variable handling that I don’t see.
neither “z” nor “squareDalitz” is null. The printf line you suggested to add gives:
*** Break *** segmentation violation
and then the same stack trace.
The we’ll need the debugger’s help. I suppose you run something like “root -l -q myScript.C”. Instead, please make sure you can compile your script, using root -l -b myScript.C+ (note tthe “+”). Once your script crashes as before (i.e. all compilation errors are fixed), please run
gdb --args root.exe -l -b myScript.C+
(yes, that “.exe” is intentional). The type “r” and the script will start and crash. Please send the output of
I am already compiling my script with the “+”.
Please find attached the gdb output.
gdb_output.txt (2.89 KB)
Okay great! Can you change “Analysis.C+” into “Analysis.C++g” (just for our debug session) and run again with gdb? Then once it crashes, send the output of “bt” from gdb.
Also, could you attach the actual code so O know what we are looking at?
the new gdb output is attached.
The whole code is here:
github.com/lecriste/Z4430_AAFit … d01fde304d
and I run it with:
root -l run_Analysys.sh
Let me know if you need also the input root files.
gdb_bt_output.txt (13.4 KB)
Argh, we need debug symbols for a different library: “sqDalitzToMassesPdf.cxx++g”. Sorry about that. Anyway, we have two options:
valgrind --num-callers=30 --suppressions=$ROOTSYS/etc/valgrind-root.supp --suppressions=$ROOTSYS/etc/valgrind-root-python.supp' --track-origins=yes root.exe -l -b ...whatever-else-you-pass-to-root...
I suspect that cosKstar is invalid at the point of use. This, too, would benefit from “sqDalitzToMassesPdf.cxx++g”.
- send the input files so I can debug this myself.
thanks for the second option
Here is the required input file:
dropbox.com/s/t0gdrn5x40fec … .root?dl=0
I did not find any run_Analysis.sh file to run your code. It would be nice if you can pack your code in a simple and minimal reproducer that we can ran easly.
One thing I notice in your snippet of code is, when binding a TF1 in a RooAbsPdf or RooAbsReal, you should make sure that the objects used to build the TF1 are still alive.
I just pushed the run_Analysis.sh file, sorry for the oversgiht:
github.com/lecriste/Z4430_AAFit … nalysys.sh
The TF2 I am currently binding in a RooAbsPdf is this one:
github.com/lecriste/Z4430_AAFit … Fit.C#L127
and I think all of the arguments are still alive when I bind it here:
github.com/lecriste/Z4430_AAFit … Fit.C#L194
I suspect the problem is caused from the fact that the TF2 you create cannot be correctly copied or clones.
I think createHistograms calls a clone of the pdf inside and this could cause the problem.
Can you maybe try by replacing createHIstogram with the asTF function ? You can always take the obtained as TF and make an histogram using the TF1::GetHistogram function ?
by replacing createHIstogram with the asTF and TF1::GetHistogram methods the code does not crash anymore.
However I noticed that the y variable I was using in the createHIstogram method was not contained in the RooAbsPdf as well. Once I make sure it is a RooAbsPdf variable, the createHIstogram method does not crash either. Perhaps createHIstogram needs some protection against such a request.
I managed to get the desired behaviour with this code:
github.com/lecriste/Z4430_AAFit … 5e1d33ff01
I have one last question:
according to the way RooFit returns the RooAbsPdf value, shall i add the Jacobian term in the evaluate method of the “derived” pdf or not?
github.com/lecriste/Z4430_AAFit … e317ab8R69