Difference between revisions of "TVModularAnalysis"

From Atlas Wiki
Jump to navigation Jump to search
 
(29 intermediate revisions by the same user not shown)
Line 1: Line 1:
===define_sample===
+
====guidelines====
The <tt>ls -1 $DIR/*.root</tt> command it used is unable to cope with very large. Replacing it with <tt>find $DIR -name '*.root'</tt> seems to do the trick.
+
<pre>
 +
Now that more people are about to start using TVModularAnalysis for their
 +
analysis I would like to propose a number of guidlines to make sure that
 +
we can work together well using a common source code.
 +
 
 +
  * Please only commit code that compiles without any errors _and_ warnings.
 +
    Long lists of existing warnings make it difficult to spot newly
 +
    introduced ones.
 +
 
 +
    --> I just cleaned all the code. There are no warnings anymore in
 +
        the present CVS head.
 +
 
 +
  * Make sure to commit coherent sets of files. For example, when you
 +
    include "MyFancyNewAnalysis.h" in CSCDriver.h, make sure that
 +
    the corresponding module is also in cvs by having 'cvs add'ed both
 +
    the .C and .h file and that it is compiled by listing it in
 +
    CCEXTRAMODS in Makefile.
 +
 
 +
    The best way to make sure that the code that you committed works OK
 +
    is (after you finished committing everything) to check out a fresh
 +
    copy of the head somewhere in /tmp and try to compile that there.
 +
 
 +
  * Do not commit binary files (.o files, executables) or auto-generated
 +
    dependencies (.d files).
 +
 
 +
  * Drivers: Since I anticipate that this will be the largest area of clashes
 +
    I have rewritten the makefile so that there can now be multiple CSCDriver
 +
    files so that each of you can have its own. As an example I have added
 +
    CSCDriverWV. To make your own
 +
 
 +
      - Add a new binary target definition to the makefile, e.g
 +
 
 +
        BINFILEWV  = CSCDriverWV
 +
 
 +
      - Add a linking rule for your new binary
 +
 
 +
        # Rules to combine objects into a private executable
 +
 
 +
          $(BINFILEWV): $(OLIST) Framework/$(BINFILEWV).o
 +
                $(CC) $(LDFLAGS) -o $(BINFILEWV) $(OLIST) Framework/$(BINFILEWV).o $(LINKLIBS)
 +
 
 +
    You can just clone my example and replace 'WV' by anything you like.
 +
 
 +
    To compile your private executable instead of the standard CSCDriver do
 +
      unix> gmake CSCDriverWV
 +
 
 +
    where you replace CSCDriverWV name with yours.
 +
 
 +
  * Before committing code, check if someone else didn't check in some
 +
    code in the meantime by either:
 +
 
 +
      - cvs diff -r HEAD (to see the differences between your files and the HEAD version)
 +
 
 +
      - cvs update (makes your code up to date with the HEAD version,
 +
                      this might change your files, so you have to compile/test them again)
 +
 
 +
  * Once you have commited a coherent set of new feature, tag the TVModularAnalysis repository
 +
 
 +
      unix> cvs tag V00-00-01
 +
 
 +
    _after_ you have committed all the changes. In the future you (and everybody else)
 +
    will be able to check out this frozen version of TVModularAnalysis even if further
 +
    changes have happened in CVS head. This allows you to separate 'production' versions
 +
    from 'development' versions.
 +
 
 +
    Send a mail to atlas-pat if you have tagged a new version of TVModularAnalysis
 +
    with a short description of the functionality you added.
 +
 
 +
    I have just tagged the current head of CVS (after cleaning and reorganization)
 +
    as 'V00-00-01'
 +
 
 +
  * Do commit your analysis modules so other can (re)use them and do
 +
    design your analysis to be performed in many small modules rather than
 +
    one large one to promote better structure, maintenance and reusability.
 +
</pre>
 +
 
 +
====define_sample====
 +
The <tt>ls -1 $DIR/*.root</tt> command it used is unable to cope with very large directories. Replacing it with <tt>find $DIR -name '*.root'</tt> seems to do the trick.
  
 
====b-tagging====
 
====b-tagging====
<pre>
+
In case you're using the Nikhef TVNtuples, you should add <tt>|| (FullReco0->
In case you're using the Nikhef TVNtuples, you should add || (FullReco0->
+
vPJet_weight(i_jet) > 4.5 && FullReco0->vPJet_p_T(i_jet)>20000)</tt> in the
vPJet_weight(i_jet) > 4.5 && FullReco0->vPJet_p_T(i_jet)>20000) in the
 
 
FillAODVectors module in TVModularAnalysis, like here:
 
FillAODVectors module in TVModularAnalysis, like here:
  
 +
<pre>
 
//--------------------------------------
 
//--------------------------------------
 
void FillAODVectors::fillBJetVec(){
 
void FillAODVectors::fillBJetVec(){
Line 17: Line 94:
 
   BJetVec.clear();
 
   BJetVec.clear();
 
   for(Int_t i_jet = 0; i_jet<FullReco0->PJet_N; i_jet++){
 
   for(Int_t i_jet = 0; i_jet<FullReco0->PJet_N; i_jet++){
     if(FullReco0->vPJet_BTagged(i_jet)==1 || (FullReco0->vPJet_weight(i_jet) >
+
     if(FullReco0->vPJet_BTagged(i_jet)==1 || ((FullReco0->vPJet_weight(i_jet) >
4.5 && FullReco0->vPJet_p_T(i_jet)>20000) ){
+
3.0 ) && (FullReco0->vPJet_p_T>15000)) ){
 
       TLorentzVectorWIdx v(FullReco0->vPJet_px(i_jet),FullReco0->vPJet_py
 
       TLorentzVectorWIdx v(FullReco0->vPJet_px(i_jet),FullReco0->vPJet_py
 
(i_jet),FullReco0->vPJet_pz(i_jet),FullReco0->vPJet_E(i_jet),i_jet);
 
(i_jet),FullReco0->vPJet_pz(i_jet),FullReco0->vPJet_E(i_jet),i_jet);
Line 27: Line 104:
 
   }
 
   }
 
}
 
}
 +
</pre>
  
 
Otherwise you don't have any b-jets, because the BTagged variable was not
 
Otherwise you don't have any b-jets, because the BTagged variable was not
 
filled. In case of the centrally produced 'Akira' Ntuples it will work just
 
filled. In case of the centrally produced 'Akira' Ntuples it will work just
 
fine the way it is now though.
 
fine the way it is now though.
</pre>
 
  
====Isolation cuts====
+
====isolation cuts====
  
 
If you like to have the same cuts as TopView, you should change in <tt>
 
If you like to have the same cuts as TopView, you should change in <tt>
 
MuonSelection.C</tt> to <tt>etcone20</tt> and the cut to 6 GeV.
 
MuonSelection.C</tt> to <tt>etcone20</tt> and the cut to 6 GeV.
 +
 +
 +
 +
====error messages====
 +
The other two warning messages still remain:
 +
<pre>
 +
Warning in <TClass::TClass>: no dictionary for class AttributeListLayout is available
 +
Warning in <TClass::TClass>: no dictionary for class pair<string,string> is available
 +
</pre>
 +
 +
We think they can be ignored safely. Though, if you're worried, a hint for a possible solution: https://twiki.cern.ch/twiki/bin/view/Atlas/EventViewFAQ
 +
 +
====missing branches====
 +
When running over ntuples, some error messages might appear:
 +
<pre>
 +
Error in <TTree::SetBranchStatus>: unknown branch -> tt_LooseCut
 +
</pre>
 +
This indicates that TVModularAnalysis is looking for the branch <tt>tt_LooseCut</tt> in the tree via one of the tree interface modules <tt>Framework/IF<treename>.[C,h]</tt> and does not find it. This is harmless unless you need this branch. In that case you should inspect the ntuple.<br>
 +
 +
If some branches are present in the ntuple, though not available in TVModularAnalysis, you should check the tree interface modules <tt>Framework/IF<treename>.[C,h]</tt> and see whether they are read in or not. If not, you might need to update the module.
 +
 +
====memory leak====
 +
The problem with the 'memory leak' has been solved: we were using "an emulated collection proxy for compiled std::vector<double> and std::vector<int>". Doh! See: https://savannah.cern.ch/bugs/?28099
 +
 +
You can check out a new version from CVS: V00-00-07
 +
 +
A bit more technical:
 +
Note that the fix is in <tt>CSCDriver.C</tt> so everybody using his/her own customised 'CSCDriver' should apply the following changes:
 +
 +
In <tt>CSCDriver.C</tt>:<br>
 +
1) Add:<br>
 +
<pre>
 +
#include "TApplication.h"
 +
#include "TROOT.h"
 +
</pre>
 +
 +
2) Change:
 +
<pre>
 +
int main(int argc, const char** argv)
 +
</pre>
 +
to
 +
<pre>
 +
int main(int argc, char** argv)
 +
</pre>
 +
 +
3) Add in <tt>main</tt>:
 +
<pre>
 +
TApplication App(argv[0],&argc,argv);
 +
gROOT->ProcessLine("#include <vector>");
 +
</pre>
 +
 +
Except for the memory leak, you also get rid off the error message that shows up everytime a new EventView-based ntuple is read in:
 +
<pre>
 +
Error in <TClass::Load>: dictionary of class TTreeIndex not found
 +
</pre>
 +
 +
====time out====
 +
When running <tt>CSCDriver</tt> on a remote PC over a ssh connection, a time out might occur. Thre problem is associated with TApplication. Possible reason is that the application is not running in 'batch' mode (i.e. it tries (and fails) to connect to the X-server). Solution: run <tt>CSCDriver</tt> in batch mode. (I guess this is not a problem as long as TVModularAnalysis is not supposed to do anything graphical).
 +
 +
<pre>
 +
  int main(int argc, char** argv)
 +
[...]
 +
  char appname[256];
 +
  char* option="-b";
 +
  strncpy(appname,argv[0],256);
 +
  char* oplist[]={appname,option};
 +
  Int_t nop=2;
 +
  TApplication App(argv[0], &nop, oplist);
 +
  gROOT->ProcessLine("#include <vector>");
 +
[...]
 +
</pre>

Latest revision as of 16:44, 15 August 2007

guidelines

Now that more people are about to start using TVModularAnalysis for their
analysis I would like to propose a number of guidlines to make sure that
we can work together well using a common source code.

   * Please only commit code that compiles without any errors _and_ warnings.
     Long lists of existing warnings make it difficult to spot newly
     introduced ones.

     --> I just cleaned all the code. There are no warnings anymore in
         the present CVS head.

   * Make sure to commit coherent sets of files. For example, when you
     include "MyFancyNewAnalysis.h" in CSCDriver.h, make sure that
     the corresponding module is also in cvs by having 'cvs add'ed both
     the .C and .h file and that it is compiled by listing it in
     CCEXTRAMODS in Makefile.

     The best way to make sure that the code that you committed works OK
     is (after you finished committing everything) to check out a fresh
     copy of the head somewhere in /tmp and try to compile that there.

   * Do not commit binary files (.o files, executables) or auto-generated
     dependencies (.d files).

   * Drivers: Since I anticipate that this will be the largest area of clashes
     I have rewritten the makefile so that there can now be multiple CSCDriver
     files so that each of you can have its own. As an example I have added
     CSCDriverWV. To make your own

       - Add a new binary target definition to the makefile, e.g

         BINFILEWV  = CSCDriverWV

       - Add a linking rule for your new binary

        # Rules to combine objects into a private executable

          $(BINFILEWV): $(OLIST) Framework/$(BINFILEWV).o
                $(CC) $(LDFLAGS) -o $(BINFILEWV) $(OLIST) Framework/$(BINFILEWV).o $(LINKLIBS)

     You can just clone my example and replace 'WV' by anything you like.

     To compile your private executable instead of the standard CSCDriver do
       unix> gmake CSCDriverWV

     where you replace CSCDriverWV name with yours.

   * Before committing code, check if someone else didn't check in some
     code in the meantime by either:

       - cvs diff -r HEAD (to see the differences between your files and the HEAD version)

       - cvs update (makes your code up to date with the HEAD version, 
                      this might change your files, so you have to compile/test them again)

   * Once you have commited a coherent set of new feature, tag the TVModularAnalysis repository

       unix> cvs tag V00-00-01

     _after_ you have committed all the changes. In the future you (and everybody else)
     will be able to check out this frozen version of TVModularAnalysis even if further
     changes have happened in CVS head. This allows you to separate 'production' versions
     from 'development' versions.

     Send a mail to atlas-pat if you have tagged a new version of TVModularAnalysis
     with a short description of the functionality you added.

     I have just tagged the current head of CVS (after cleaning and reorganization)
     as 'V00-00-01'

  * Do commit your analysis modules so other can (re)use them and do
    design your analysis to be performed in many small modules rather than
    one large one to promote better structure, maintenance and reusability.

define_sample

The ls -1 $DIR/*.root command it used is unable to cope with very large directories. Replacing it with find $DIR -name '*.root' seems to do the trick.

b-tagging

In case you're using the Nikhef TVNtuples, you should add || (FullReco0-> vPJet_weight(i_jet) > 4.5 && FullReco0->vPJet_p_T(i_jet)>20000) in the FillAODVectors module in TVModularAnalysis, like here:

//--------------------------------------
void FillAODVectors::fillBJetVec(){
//--------------------------------------
//----------------------------------------------------------------------
// Fill Vectors of TLorentzVectors-with-index for 'all' and 'good' Bjets
//----------------------------------------------------------------------
  vector<TLorentzVectorWIdx>& BJetVec      = gList["BJetVec"] ;
  BJetVec.clear();
  for(Int_t i_jet = 0; i_jet<FullReco0->PJet_N; i_jet++){
    if(FullReco0->vPJet_BTagged(i_jet)==1 || ((FullReco0->vPJet_weight(i_jet) >
3.0 ) && (FullReco0->vPJet_p_T>15000)) ){
      TLorentzVectorWIdx v(FullReco0->vPJet_px(i_jet),FullReco0->vPJet_py
(i_jet),FullReco0->vPJet_pz(i_jet),FullReco0->vPJet_E(i_jet),i_jet);
      BJetVec.push_back(TLorentzVectorWIdx(FullReco0->vPJet_px
(i_jet),FullReco0->vPJet_py(i_jet),FullReco0->vPJet_pz(i_jet),FullReco0->
vPJet_E(i_jet),i_jet) );
    }
  }
}

Otherwise you don't have any b-jets, because the BTagged variable was not filled. In case of the centrally produced 'Akira' Ntuples it will work just fine the way it is now though.

isolation cuts

If you like to have the same cuts as TopView, you should change in MuonSelection.C to etcone20 and the cut to 6 GeV.


error messages

The other two warning messages still remain:

Warning in <TClass::TClass>: no dictionary for class AttributeListLayout is available
Warning in <TClass::TClass>: no dictionary for class pair<string,string> is available

We think they can be ignored safely. Though, if you're worried, a hint for a possible solution: https://twiki.cern.ch/twiki/bin/view/Atlas/EventViewFAQ

missing branches

When running over ntuples, some error messages might appear:

Error in <TTree::SetBranchStatus>: unknown branch -> tt_LooseCut

This indicates that TVModularAnalysis is looking for the branch tt_LooseCut in the tree via one of the tree interface modules Framework/IF<treename>.[C,h] and does not find it. This is harmless unless you need this branch. In that case you should inspect the ntuple.

If some branches are present in the ntuple, though not available in TVModularAnalysis, you should check the tree interface modules Framework/IF<treename>.[C,h] and see whether they are read in or not. If not, you might need to update the module.

memory leak

The problem with the 'memory leak' has been solved: we were using "an emulated collection proxy for compiled std::vector<double> and std::vector<int>". Doh! See: https://savannah.cern.ch/bugs/?28099

You can check out a new version from CVS: V00-00-07

A bit more technical: Note that the fix is in CSCDriver.C so everybody using his/her own customised 'CSCDriver' should apply the following changes:

In CSCDriver.C:
1) Add:

#include "TApplication.h"
#include "TROOT.h"

2) Change:

int main(int argc, const char** argv)

to

int main(int argc, char** argv)

3) Add in main:

TApplication App(argv[0],&argc,argv);
gROOT->ProcessLine("#include <vector>");

Except for the memory leak, you also get rid off the error message that shows up everytime a new EventView-based ntuple is read in:

Error in <TClass::Load>: dictionary of class TTreeIndex not found

time out

When running CSCDriver on a remote PC over a ssh connection, a time out might occur. Thre problem is associated with TApplication. Possible reason is that the application is not running in 'batch' mode (i.e. it tries (and fails) to connect to the X-server). Solution: run CSCDriver in batch mode. (I guess this is not a problem as long as TVModularAnalysis is not supposed to do anything graphical).

  int main(int argc, char** argv)
[...]
  char appname[256];
  char* option="-b";
  strncpy(appname,argv[0],256);
  char* oplist[]={appname,option};
  Int_t nop=2;
  TApplication App(argv[0], &nop, oplist);
  gROOT->ProcessLine("#include <vector>");
[...]