Re: SuperMonitor for Offline analysis

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Fri Jun 09 2000 - 05:22:55 EDT

  • Next message: hagel@comp.tamu.edu: "Re: Super Monitor"

    Hej Ian, 
    
    On Fri, 09 Jun 2000 10:42:17 +0200 "I. G. Bearden" <bearden@hehi03.nbi.dk> wrote:
    > You can find a (not great, but working)
    > example of such a program in
    > ~bearden/Scripts/TOFanalyze.C
    
    Though it may work in interactive ROOT, it is far from OK, especially
    if you'd like compiled code. The most important recommendation (see
    reasons listed below), is to _always_ state the type of pointers and
    so on. That is, instead of:
    
      fubar = new TFubar("Fucked Up Beyond All Repair")
    
    _always_ do:
    
      TFoo* foo = new TFoo("Foo is wonderful, and so is Bar");  
    
    Here is what I wrote to Djamel on that script: 
    
    To: ouerdane@nbi.dk, videbaek@sgs1.hirg.bnl.gov
    
    On Fri, 09 Jun 2000 00:52:13 +0200 (MET DST) Djamel Ouerdane <ouerdane@nbi.dk> wrote:
    > Hi Christian,
    > 
    > How are you doing?
    
    Ca va! Styding for my exam ... (yawn)
    
    > Here, well, things are running quite good. We have both beams though not
    > stable and are able to record preliminary data.
    
    Tres bien. When will there be collisions?
     
    > I need to know something, since Flemming was not sure about it.
    
    Ok. 
    
    > I have a root macro that works fine but slowly when reading events from a
    > data file (I'm doing offline analyses). If you read my email about the
    > super monitor, you'll understand why I'm using this macro. 
    
    I did, and I think I undestand. 
    
    > It was written
    > originally by Ian (TOFanalyze.C on a pii machine in ~bearden/Scripts).
    > I have modified it somehow but also Flemming told me that the speed could
    > be increased if I create a shared library this way:
    
    Ok. What I have to say below, is somewhat dependent on what changes
    you made, so if what I propose doesn't work, please send me the macro
    with you modifications.  
    
    > root[1] .x BratLoad.C  (works like that here)
    > root[2] .L TOFanalyze.C .c++
    
    First of, it should be: 
    
       root[0] .x BratLoad.C  // (works like that here)
    
    Yeah. Kris and/or flemming seem reluctant to make "bratroot"
    avaliable. However, I think you can do 
    
       prompt% $BRATSYS/test/bratroot 
    
    but I'm not totally sure. Anyway, the next line is wrong. Rather you
    should do:
    
       root[1] .L TOFanalyze.C++ 
                             ^^^
                             |||
    
    That's the syntax for the "script-compiler". So far so good. 
     
    > and yes, root tries to do it but says that it can't find the include files
    > I have put at the top of the macro.
    
    Hmm. Header files in a macro is somewhat tricky (a CINT feature), but
    I don't think that's the problem. What I _do_ think is the problem is
    lines like: 
    
      hADC03t = new TH1F("hADC03t","SLat18",1024,0.,4096.);
    
    Using this line only, what type is hADC03t!? If you say a pointer to
    TH1F, you're wrong - because it needn't be! It could be anything. The
    problem is, that this line is not syntactical correct. 
    
    In interactive ROOT, this is no problem, 'cause CINT is (sort of)
    "smart" and makes hADC03t a pointer to TH1F. If this sounds familiar,
    it's because it sort of is - remember Fortran77 and
    "IMPLICIT". Perhaps, CINT should have an "IMPLICIT NONE" construct! 
    
    However, when you invoke the script compiler, the actual compiler
    (EGCS 1.1.2, C++) actually gets invoked behind your back. Now, the
    compiler won't compile syntactically incorrect code - ofcourse.
    
    So, in short, the solution is to excplicitly state what types your
    variables are: 
    
      TH1F* hADC03t = new TH1F("hADC03t","SLat18",1024,0.,4096.);
    
    Actually, this is not really the solution. Looking over the script
    TOFanalyse.C, there is a real scope problem! For instance, in one
    function you have: 
    
      void OpenRootFile() 
      {
        RootFile = new BrEventIO("tof test");
        ...
      }
    
    and in another function, you have: 
    
      void GetRootEvent()
      {
        ...
        RootFile->Event(digitized_node); 
      }
    
    Again, this is mal-formed. Looking at these lines, what scope does
    RootFile have!? If you say global, you're wrong. The pointer RootFile
    in OpenRootFile() has scope of that function, while the pointer
    RootFile in GetRootEvent() has scope of that function - i.e., they are
    two different pointers. 
    
    Why this may work in interactive ROOT (though it seems wrong to me),
    is once again due to the "smart-ness" of CINT. The pointer RootFile is
    declared in global scope as a pointer to a BrEventIO object. 
    
    Of course the compiler will choke on the mal-formed code. 
    
    The solution is to declare RootFile, and similar shared pointers and
    objects, in global scope: 
    
      BrEvent* RootFile = 0;
     
      void OpenRootFile() 
      {
        RootFile = new BrEventIO("tof test");
        ...
      }
      void GetRootEvent()
      {
        ...
        RootFile->Event(digitized_node); 
      }
    
    However, this is still somewhat of a hack. The script TOFanalyse.C is
    406 lines long! Now obviously, you're gonna enlarge running time in
    some proportion to the lenght of a script file. So what is the
    solution you ask!? Well, Flemming advice, while in prinicple OK, can
    be improved opon. My advice is to make a proper class:
    
      // file: TofAnalyse.h, to be edited in -*- mode: c++ -*-  
      #ifndef TOFAnalyse_h
      #define TOFAnalyse_h
      class TObject;   // forward declaration
      class BrEventIO; // forward declaration
      class TH1F;      // forward declaration
      ... and other forward declaration needed
      
      class TofAnalyse : public TObject {
      private:
        BrEventIO* fRootFile   
        TH1F*      fHADC03t
        ... and other shared objects/pointers/variables (members)
      public:
        TofAnalyse();
        void OpenRootFile(void);    
        void GetRootEvent(void); 
        ... and other functions (methods)
        ClassDef(TofAnalyse,0) // My TOF analysis class 
      };
      #endif // TOFAnalyse_h
      // end of file: TofAnalyse.h 
     
      // file: TofAnalyse.cxx 
      #include <BrEventIO.h>
      #include <TH1F.h>
    
      TofAnalyse::TofAnalyse(void) {
        // setup code
        ...
      }
    
      TofAnalyse::void OpenRootFile() 
      {
        RootFile = new BrEventIO("tof test");
        ...
      }
      TofAnalyse::void GetRootEvent()
      {
        ...
        RootFile->Event(digitized_node); 
      }
      ... and the rest of the method definitions
      // end of file TofAnalyse.cxx 
    
    and then compile it into a shared library: 
    
      prompt% ls 
      TofAnalyse.cxx   TofAnalyse.h 
      prompt% g++ -I./ `root-config --cflags` `brat-config --cflags` \ 
    	  -c -Wall -g -o TofAnalyse.o TofAnalyse.cxx
      prompt% rootcint -f TofAnalyseCint.cxx -c -I./ \
    		   `brat-config --cflags` TofAnalyse.h 
      prompt% g++ -I./ `root-config --cflags` `brat-config --cflags` \ 
    	  -c -Wall -g -o TofAnalyseCint.o TofAnalyseCint.cxx
      prompt% g++ -shared -Wl,-soname,TofAnalyse.so -o TofAnalyse.so \
    	  TofAnalyse.o TofAnalyseCint.o
      prompt% ls
      TofAnalyse.cxx  TofAnalyse.o   TofAnalyseCint.cxx   TofAnalyseCint.o
      TofAnalyse.h    TofAnalyse.so  TofAnalyseCint.h     
    
    and then finally in the interactive ROOT: 
    
      root[0] .x BratLoad.C 
      root[1] .L TofAnalyse.so 
      root[2] TofAnalyse* ana = new TofAnalyse;
      root[3] ...
    
    Hope that helps, au revior 
    
    Christian  -----------------------------------------------------------
    Holm Christensen                             Phone:  (+45) 35 35 96 91 
      Sankt Hansgade 23, 1. th.                  Office: (+45) 353  25 305 
      DK-2200 Copenhagen N                       Web:    www.nbi.dk/~cholm    
      Denmark                                    Email:       cholm@nbi.dk
    



    This archive was generated by hypermail 2b29 : Fri Jun 09 2000 - 05:27:05 EDT