ecounter a problem when using the TTreeReader. I want to read in a TMatrixD from a root file. It works fine when I am just using a tree i.e.:
TMatrixD *trackIDsMatrix = new TMatrixD();
TTree *tree = (TTree *)inFile->Get("clusters");
tree->SetBranchAddress("trackIDsPerCluster", &trackIDsMatrix);
// for testing get number of rows of first entry
tree->GetEntry(0);
std::cout << "Number of rows: " << trackIDsMatrix->GetNrows() << std::endl;
However I would like to use the TTreeReader (I am using it successfully for all the other entries). Unfortunately when I am trying that:
I just tried your first example (just in the root prompt) and I receive the same error as before, that the type is unknown:
root [0] TFile f("f.root");
root [1] TTreeReader r("t", &f);
root [2] TTreeReaderValue<TMatrixD> rv(r,"m");
root [3] r.Next();
Error in <TTreeReaderValueBase::GetBranchDataType()>: Unknown type and class combination: -1, TMatrixT<double>
Error in <TTreeReaderValueBase::CreateProxy()>: The branch m contains data of type {UNDETERMINED TYPE}, which does not have a dictionary.
So I guess there is probably some error with my root setup. I am working in an analysis framework of my experiment with an init script which does the following:
I checked ROOTSYS, my PATH and the LD_LIBARARY_PATH and they seem to be correctly set.
Do you have an idea?
I also had a look on DF, thanks, that seems to be very interesting and useful also for other applications in our software. Unfortunately when I try to use it (not only with the analysis framework setup but also with the newest root-version), I get an error that ‘RDaraFrame’ in namespace ‘ROOT’ is not known.
thanks for digging further and trying out things. I think this is a bug in 6.08 which was not backported. ROOT 6.08 dates 2 years back and the last patch was released 18 months ago.
Can we help you moving your setup to ROOT 6.14?
ok, thanks, I just thought it is a problem with my setup. And yes it works in my other setups where I am using a newer LCG release.
Unfortunately I am not sure I can move, because I would also need to update the whole framework to be compiling with at least gcc62 and I do not intend to do that in this specific case.
I really appreciate your flexibility. Unfortunately even if we’d fix it for 6.08, which we do not usually do given the release date, the change would not be available soon: we’d need another 6.08 patch release.
Let me know if I can do anything more and if this blocks you somehow.