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.
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:
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).
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).
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.
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.
[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.
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.
[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.
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.
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.
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’?
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
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.
