Home | News | Documentation | Download

Problems with <vector<vector<int> >

Hi,

I’m having problems reading my branches in my ROOT file e.g.:
vector<vector > *mc_parents;

After searching through old threads, I found this:

that seems to indicate the correct recipe is to create Loader.C with:

#include<vector>
#ifdef __CINT__
#pragma link C++ class vector<vector<int> >;
#else
template class std::vector<std::vector<int> >;
#endif

where I added an extra “>” that seemed to be missing in the original code linked from thread above.

But unfortunately this did not work for me, even after doing:

gROOT.ProcessLine('.L Loader.C+')

at the beginning of my PyROOT script, I still get the error:

This is the same error as I get if I do not load Loader.C. Since this recipe seemed to work for the previous user, am I doing something wrong or missing something obvious? I have looked through my code but can’t see what might be wrong.

Thanks in advance,
Eric

Strangely, if I instead do:

from ROOT import *
f = TFile("data.root")
t=f.Get("qcd")     # get the TTree
t.Scan("mc_parents")
***********************************
*    Row   * Instance * mc_parent *
***********************************
*        0 *        0 *         3 *
*        0 *        1 *         4 *
<etc>

i.e. TTree::Scan() seems to work fine on the vector<vector > branch, but in my macro I cannot do:

print len(t.mc_parents)     # This fails with the error reported above

Is there some reason why this is?

Thanks,
Eric

After further digging on the forum, it seems that processing Loader.C does not work if one sets up the ATLAS Athena environment, which is what I was doing first, in order to get consistent versions of ROOT and Python. Not sure why this is, if anyone has any explanation that would be very useful to know.

Instead I have now gotten it to work by setting up with:

source /afs/cern.ch/sw/lcg/contrib/gcc/4.3/x86_64-slc5-gcc43-opt/setup.sh
export ROOTSYS=/afs/cern.ch/sw/lcg/app/releases/ROOT/5.26.00/x86_64-slc5-gcc43-opt/root
export PATH=/afs/cern.ch/sw/lcg/external/Python/2.5.4p2/x86_64-slc5-gcc43-opt/bin:$ROOTSYS/bin:$PATH
export LD_LIBRARY_PATH=$ROOTSYS/lib:/afs/cern.ch/sw/lcg/external/Python/2.5.4p2/x86_64-slc5-gcc43-opt/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$PYTHONPATH:$ROOTSYS/lib

as described here:
/viewtopic.php?t=7191

Eric.

just guessing, but the new environment that you chose is 64b, whereas the ATLAS one would be 32b binaries. If so, then I think that ACLiC must be told to set the -m32 option in the ATLAS case, by changing its options (gSystem->SetMakeSharedLib() IIRC).

Cheers,
Wim

Hi,

I have a related problem, trying to link against vector<vector<...> > while using the ATHENA version of ROOT.

I must use ROOT within Athena since running on the grid requires to specify the Athena tag, and even if you are running standalone ROOT applications, you must do it with the Athena version of ROOT…

When using a standalone ROOT (from lxplus) there were no problems as expected.

This is the syntax i’m using:

-------------------------------------------------------------- ... #include <vector> using namespace std; #ifdef __MAKECINT__ #pragma link C++ class vector<vector<float> >+; #else template class vector<vector<float> >; #endif ... --------------------------------------------------------------

I need to be able to read these types from the datasets - the ATLAS flat ntuples (D3PDs).

Does anyone knows the solution ???

Cheers,
Noam

Hi Noam,

What is the error(s) in your case?

Philippe.

Hi Philippe,

My errors are the same as reported in the first post,
Here’s an example

Note: Link requested for undefined class vector<vector > (ignore this message) :0:
Error: A dictionary has been requested for vector<vector > but there is no declaration!

Note that this occurs only when I use the Athena version of ROOT whereas, with a standalone ROOT version it is error-less.

Thanks,
Noam

Hi Noam,

I suspect that this means that the Atlas build environment is either missing any of the directories
$ROOTSYS/cint/cint/include $ROOTSYS/cint/cint/lib and $ROOTSYS/cint/cint/stl or managed to insert an empty version of the vector header file in the list of directories that cint is looking at.

Philippe.

Thanks Philippe,

Do you think that I can

  1. #include the necessary headers in my code, independent from the athena-ROOT (using the headers a of the standalone ROOT version)
  2. likewise, link against the necessary libs independent from the athena-ROOT

???

If yes, what would be the relevant headers and libs ???

Thanks,
Noam

Hi,

[quote]1. #include the necessary headers in my code, independent from the athena-ROOT (using the headers a of the standalone ROOT version)[/quote]That depends on what the problem is. If directories $ROOTSYS/cint/cint/… do not exist on your installation, then there is not much you can do (i.e. the installation is broken!). If instead there is a weird file in the way, we might be able to work-around it.

The include you need is simply:#include <vector>the fact that your code work in standalone ROOT means that you already have it.

Cheers,
Philippe.

Philippe,

ATLAS ROOT installations are taken from LCG so I’m rather certain that nothing funny is happening there. Rather, the issue might be the that the std::vector<> is (also) available through Reflex first.

Cheers,
Wim

Hi Wim,

[quote]Rather, the issue might be the that the std::vector<> is (also) available through Reflex first.[/quote]humm … yes it is plausible. Let me see if I can reproduce that case.

Thanks,
Philippe.

Hi Wim and Philippe,

Thanks a lot for your help,

I tried to change things, to run on different machines, different ROOT versions and didn’t mange to get a consistent behavior - even not for the errors.

I was digging a lot in many forums and saw that this is a common problem where I didn’t saw that there is a clear magical solution.

This isn’t like me, but I’ll give up for now - will simply not use the special types until this is sorted somehow.

Thanks,
Noam

Noam,

if it is Reflex, and a Reflex dictionary within an ATLAS environment works for you, then you can make vector<vector > work by doing:

root [0] gSystem->Load( "libCintex.so" ); root [1] Cintex::Cintex::Enable(); root [2] vector<vector<float> > v; root [3] v (class vector<vector<float> >)149561576 root [4]
Cheers,
Wim

Hi Wim,
Thanks,

I didn’t understand the syntax and purpose of the last line:
v(class vector<vector >)149561576

Noam

Noam,

no other reason that showing that this works. W/o Cintex (and the implicit loading of the std::vector<vector > dict that comes with ATLAS setups), that line would fail.

Cheers,
Wim

Hey guys,

I’ve spotted the same problem trying to read vector<vector> from ntuples. The thing is that when I use ROOT on lxplus (5.27.02) it works fine with

#include <vector> #ifdef __MAKECINT__ #pragma link C++ class vector<vector<float> >+; #endif

(it is not some kinda loader.C, I just put these lines in my .c analysis code between last #include and first function). As soon as I send it to some backend in the GRID via prun it crashes there. I dug a little dipper and understood that as soon as athena gets initialized (even on lxplus) I can no more run my script - it will crash with

Error: Can't call vector<vector<float> >::at(trkpt5_trackNumber) in current scope myanalysis.c:699: Possible candidates are... (in vector<vector<float> >) Error: non class,struct,union object at(trkpt5_trackNumber) used with . or -> myanalysis.c:699: *** Interpreter error recovered ***

I guess the same thing happens when I send it to the GRID - athena gets initialized and all crashes.

So maybe athena starts to use some ROOT version that does not know how to deal with vector of vectors - in that case all we have to do is to force athena to use same ROOT version that works fine on lxplus. But how to do this (if it’s possible at all)? Or just to find and use some athena version running with “good” ROOT version - for me it’ll be enough I guess.

If it is not the case, then we definitely need some workaround. The main idea here is that we do not need to send our jobs to the GRID while debugging this issue - we simply initialize athena with asetup … and run the script.
Any ideas or some progress since last post?
Thanks!

[quote]The main idea here is that we do not need to send our jobs to the GRID while debugging this issue - we simply initialize athena with asetup … and run the script.[/quote]In order for the script do actually generate the dictionary, it need to be compile with ACLiC. I.e. it need to be loaded with the equivalent of .L script.C+, is that what you do when you ‘run the script with athena’?

Philippe.

Hi Philippe,

no, with athena I try exactly the same as without it: just root -l myanalysis.c
Without athena it works, with - it does not.

Earlier I used to generate this dictionary with ACLiC - I’ve put these lines inside loader.C and did .L loader.C+, then running my script. But then I realized that it is not necessary, I can simply put them inside myanalysis.c and run it. And I expected same behavior from configuration “with athena”. But obviously I was wrong :frowning:

Hi,

Are the version of ROOT the same in both case?

Philippe.

PS. If not, this means that you are relying on a newer feature of ROOT (the auto dictionary loader … which does the .L loader.C+ for you essentially) … and in this case you simply have the compile the loader.C+ when using the older version of ROOT.