RDataFrame and vectors of booleans

Hi,

I have a tree that contains a vector of booleans and want to use RDataFrame to process it. When trying to filter using the branch or when using Define to create a new column I get an error like this:

/cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/etc/../include/ROOT/RDFNodes.hxx:888:15: error: no matching constructor for initialization of 'ROOT::VecOps::RVec<bool>'
             T tvec(readerArrayAddr, readerArraySize);
              ^    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

, followed by a segmentation violation.

I made a minimal python code example and a snapshot (snapshot.root (6.1 KB)) of the relevant branches of the tree to reproduce the issue

import ROOT

rdf = ROOT.RDataFrame("digi", "snapshot.root")

h2 = rdf.Define("fit_converged_scint_plus_spike_1st", "fit_converged_scint_plus_spike[0]")\
        .Histo1D("fit_converged_scint_plus_spike_1st")
h2.Draw()

I have also tried ROOT version 6.15.02 after finding what I thought was a related issue (Crash when saving bool arrays using Snapshot), where I do not get any error message anymore but only the segmentation violation.

Is there another way to work with a vector in an RDataFrame?

Thanks,
Thomas


_ROOT Version: 6.14.04
_Platform: slc6
_Compiler: gcc 6.2


Hi Thomas,

thanks for reporting. We are aware of this issue.
This has been fixed in the 6.16 branch and will be part of the forthcoming 6.16 release.
Can we help you set up a build on the master/6.16 branch in order to unblock you?

Cheers,
D

Hi,

thanks for the quick reply.
On my local machine moving to 6.16 should be no issue. On the batch system I might need to wait until it is available on cvmfs if I do not want to compile myself.

As a workaround, is there a way to change the type of the branch (to vector<int> for example) before initialising the RDataFrame?

Best regards,
Thomas

Hi Thomas,

unfortunately there is no workaround but there is a CVMFS setup that allows you to use the most recent ROOT build. In the directory /cvmfs/sft.cern.ch/lcg/views/dev3/latest you see the latest nightly of the LCG build against the newest ROOT. Just pick the directory relative to the OS in the batch system and source the setup.sh script to setup the environment.

Cheers,
D

Hi Danilo,

thanks for the advise. However, I have tried all the slc6 versions in the directory you pointed to and even tried on a cc7 system but none of them could run the code successfully. It always led to a segfault.

Compiling from master or v6-16-00-rc1 resulted in an error with a missing file ./include/ROOT/RVec.hxx:37:10: fatal error: 'vdt/vdtMath.h' file not found.

Regards,
Thomas

Hi Thomas,

it is very odd that the LCG releases do not work. Both LHCb and ATLAS tested them and hundreds of users battle tested them on the CERN SWAN service. How exactly did you source the script?

I let @amadio comment about the missing VDT in detail but I would suggest to try to configure with the -Dbuiltin-vdt=ON switch if possible.

Cheers,
D

The VDT problem is due to a missing include directory that needs to be hidden because when VDT is builtin it would point to the build directory. This has been fixed in master as far as I can tell, but if you use root-config it has no notion to add extra includes for external dependencies of ROOT, so you’ll need to add the extra includes by hand, unfortunately.

Hi Danilo,

yes I find that odd as well that the LDG build does not work. I simply sourced the setup.sh like this:
source /cvmfs/sft.cern.ch/lcg/views/dev3/latest/x86_64-slc6-gcc62-opt/setup.sh and I when I start ROOT afterwards and run gROOT->GetVersion() it shows me “6.17/01”. To be sure I have also disabled my .rootlogon.C but that did not change things.

With the -D builtin-vdt=OFF option I could build root locally from master but also there the segmentation violation remains.

Regards,
Thomas

Hi,

I spent some more time trying to figure this out without success and since others could also reproduce the issue I submitted a bug report.
https://sft.its.cern.ch/jira/browse/ROOT-9866

Best regards,
Thomas

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.