TypeError: can not resolve method template call for 'Profile1D'
the same happens for Profile2D. Am I typing the command wrong? if so which is the
correct way to call the method in python? (C++ version on the same tree runs fine)
Hi Simone,
your command is just fine, or better will be, since the feature is simply not there yet.
Support for Profile{1D,2D} is coming to master soon and will be part of the upcoming 6.12 ROOT release.
Thank you for trying out TDF, do not hesitate to let us know what else is missing for PyROOT users!
first of all: thanks for having a look to the bleeding edge and giving feedback!
As Enrico says: it’s in the making. We implemented histograms in master and, given that no conceptual challenge was ahead of us for profiles, we decided to tackle more difficult aspects such as caching of datasets’ columns in memory for faster (re)processing (see https://root.cern/doc/master/classROOT_1_1Experimental_1_1TDF_1_1TInterface.html#a68fbd9949eb20ddc759e1e93a0663782): the November release, 6.12, is really behind the corner and we need careful prioritisation.
We’ll do our best to squeeze into the release a PyROOT friendly way of dealing with profiles as well as a more powerful way to define columns and filters.
my use case is the following: I have friend trees produced by an analysis software (or better by a software that deals with the reconstruction of test beam data) on top of these trees I have a python script that runs the analysis/makes plots. Everything works fine but it’s quite slow and not suitable for a prompt analysis (i.e. DQM), although I can speed thinks up using TTreeFormula, TDataFrame could be a great way to achieve speed while keeping the code simple, clean and generic.
thanks for the explanation.
One thing that can be done now, if MT is not crucial, is to deal with friend trees as in the example. We’ll see what to do next.
great.
This breaks, even if slightly, the “universality” of TDF in the sequential and parallel case. For us, up to now, this has been a must and I think it should continue to be. In other words, we are not giving up here, just prioritising and keeping you advance with your DQM code
are there known problems in mixing friends and the issue we discussed in this other topic:
When I try your recipe it works for arrays in the main tree but not for those in the friends. The Define call doesn’t work also for non-array variables stored in the friends.
Hi,
yes support of friend trees is not completely there. I just opened PR 1135 to resolve the most obvious issue, that is what you are probably seeing now.
Hi @simonepigazzini,
we are testing friend trees support and we cannot reproduce failures when reading arrays from friend trees.
Can you copy-paste the problematic line and the output of TTree::Print for the corresponding branch?
This works for us:
TFile f1(kFile1);
TTree *t1 = static_cast<TTree *>(f1.Get("t"));
t1->AddFriend("t3", kFile3);
TDataFrame d(*t1);
auto checkArr = [](std::array_view<float> av) {
for (auto x : av)
std::cout << x << " ";
std::cout << "\n";
};
d.Foreach(checkArr, {"arr"});
Commenting on this closed topic to let @simonepigazzini know that master now has support for TDataFrame+friend trees, both in single- and multi-thread execution. Please let us know if you encounter any problem