Dear ROOT experts,
I have a question concerning the design philosophy of custom object fills using RDataFrames.
I have a program which I have adapted from sinlge-threaded TTree loop to an RDataFrame graph with implicit multithreading. My program defined its own class for computing 2-dimensional sidebands, SB2x2D, which implements it’s own Fill method that essentially fills a collection of histograms associated with the SB2x2D object. I have adapted this class to hold, in addition to the histograms themselves, a RResultPtr for each histogram so that the histograms can be initialized using the RDF::Histo1d method (wrapped inside another method on SB2x2D) during the defintion of the run graph. The Fill method on SB2x2Dthen finally collects the THX object using GetValue, executing the run graph.
I have noticed that this leads to some weird behaviour as soon as I define multiple SB2x2D objects in order to fill them, creating a new RDataFrame for each of them. The RResultPtr members SB2x2D sometimes point to the results of previous fills, unless I explicitly call RDF_hN_2D.GetSharedPtr().reset(); at the end of Fill. I am wondering if this is bad design on my part. The ownership of the RResultPtr object is effectively shared between the RDataFrame and SB2x2Dobjects, which creates ambiguities whenever either RDataFrames or SB2x2Ds are created or destroyed. I understand there is a way to create new objects inside the run graph of the RDataFrame using the book method, to make sure they go out of scope when the RDF is finished – however I have also read that this method is quite limited wrt. the kinds ofobject you can book. In my case, my SB2x2D class also includes methods for performing fits on the histograms and is designed to persist between fills. How would you handle this problem? Looking forward to hearing your advice.
Cheers,
Alex
ROOT Version: 6.36
Platform: Linux
Compiler: Not Provided