Is it possible to persistify RooKeysPdf?

ROOT
1

Hello,

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.
Ashfaq

2

Hi,

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.

Wouter

3

Hello,

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
x->setVal(x1);
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>!
aborting
(no debugging symbols found)
Using host libthread_db library “/lib64/tls/libthread_db.so.1”.
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/libc.so.6
#2 0x005987a9 in do_system () from /lib/tls/libc.so.6
#3 0x006c898d in system () from /lib/tls/libpthread.so.0
#4 0xf7b9279f in TUnixSystem::Exec () from /afs/cern.ch/sw/lcg/external/root/5.18.00a/slc4_ia32_gcc34/root/lib/libCore.so…

Thanks again,
Ashfaq

4

Hi,

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

Wouter

5

Hello,

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:

Thanks,
Ashfaq