Is it possible to persistify RooKeysPdf?


Each time when I construct RooKeysPdf it takes quite some time. The time depends on the numbers of events(several minutes for few tens of thousand). I am wondering whether there is a way to write RooKeysPdf to file in such a way that it could be read easily and efficiently in the next iteration?

Thanks for your help.


You should be able to use the general persistence mechanism in RooFit available as of ROOT version 5.18. This works as follows

Writing session for a myPdf with name “MyPdf” with observable x (“x”) ;

root> RooWorkspace w(“w”,“my workspace”) ;
root> w.import(myPdf) ;
root> TFile f(“blah.root”,“RECREATE”) ;
root> w.Write() ;
root> f.Close() ;

Reading session

root> TFile f(“blah.root”) ;
root> RooAbsPdf* myPdf = w.pdf(“MyPdf”) ;
root> RooRealVar* x = w.var(“x”) ;

The above code should not only work for a single p.d.f like RooKeysPdf, but also for composite p.d.f.s for which all components and variables are automatically and recursively imported into the workspace. You can do a Print() on the workspace to see what is in there.



Thanks for your help but the above doesn’t work for me in interactive sessions. I am using ROOT 5.18/00a. In the compile code I am able to write to a file as you suggested but when I try to read back the Pdf then it crashes with the error given below. The same happens in compile code as well. I could send a complete traceback if that would be helpful.

I would also like to mention what I aim to do(once the crash is fixed) is the following,

TFile f(“myKeysPdf.root”) ;
RooKeysPdf myKeysPdf = dynamic_cast<RooKeysPdf> ( w.pdf(“myPdf”) ) ;
RooRealVar* x = w.var(“x”) ;

//for x=x1, get the value of pdf
myKeysPdf->getVal( &RooArgSet(x) ) ;
does this seem ok?

And the crash is here,

root [0] TFile f(“myKeysPdf.root”);
root [1] RooAbsPdf* myPdf = w.pdf(“myPdf”) ;
Fatal in : Could not find pair<string,string>!
(no debugging symbols found)
Using host libthread_db library “/lib64/tls/”.
Attaching to program: /proc/30097/exe, process 30097
(no debugging symbols found)…done.
(no debugging symbols found)…done.
[Thread debugging using libthread_db enabled]
[New Thread 4148319936 (LWP 30097)]
(no debugging symbols found)…done.
(no debugging symbols found)…done.
(no debugging symbols found)…done.
(no debugging symbols found)…done.
(no debugging symbols found)…done.

0xffffe410 in __kernel_vsyscall ()
#1 0x005eed23 in __waitpid_nocancel () from /lib/tls/
#2 0x005987a9 in do_system () from /lib/tls/
#3 0x006c898d in system () from /lib/tls/
#4 0xf7b9279f in TUnixSystem::Exec () from /afs/…

Thanks again,


I’ll try to reproduce this myself. I’ll get back to you shortly.



I seem to have found a fix. If I do “ROOT::Cintex::Cintex::Enable()” in a ROOT session then things seem working. My use case is a bit complicated, I want to use it inside my code which run in ATLAS athena framework. In order to use “ROOT::Cintex::Cintex::Enable()” inside my algorithm I have to link my code against Cintex library which I would not like but have no other choice, at least this is the work around I found for now. With this I am able to read/write keys Pdf.
Please let me know if you have any better suggestion for my use case.

BTW before we use to do only Cintex::Enable() but in ROOT 5.18 it doesn’t work, now I have to do ROOT::Cintex::Cintex::Enable(). It seems the number of Cintex’s increment with each new release :slight_smile: