Proposing BRAT/bratmain addition (PLEASE READ!)

From: Bjorn H Samset (bjornhs@rcf2.rhic.bnl.gov)
Date: Tue Dec 10 2002 - 14:24:28 EST

  • Next message: Djamel Ouerdane: "Re: Proposing BRAT/bratmain addition (PLEASE READ!)"
    Hello dev'ils.
    
    A short time back we had a discussion on possible improvements to our
    analysis framework, and one of the things that came up was the need for a
    consistent way of documenting and recreating the running conditions of a
    bratmain job. (What I will below call a 'snapshot'.)
    
    I've discussed this somewhat with Flemming, and we've agreed on a possible
    way to implement this and I've made a test of it for a few classes. I'd
    like to describe here what we'd like to do so that you can all give some
    feedback before I get too far in the process.
    
    NB: This will be a major addition to brat, in that it adds a (small)
    method to each and every module and adds a new required flag to bratmain.
    Therefore, please read this and comment!
    
    What I'm currently implementing is this:
    
    In bratmain, there will be an option
     -l  --log              Logfile name, default is bratmainSnapshot.log
    
    The snapshot file, here bratmainSnapshot.log, is simply an ascii file -
    see below for the contents. This is the only part that the user will have
    to worry about, i.e. to set this logname to something useful. In the
    bratmain script, one more line is added: (also added to the brat-help lisp
    functions, so dont't worry)
      // The main module
      //
      BrMainModule* mainModule =
        new BrMainModule("testScript", "TestScript",
                         "Bjorn H. Samset", 0, 1, 0);
      mainModule->SetMaxEvents(eventsOption->GetValue());
      mainModule->SetMaxRuns(maxrunsOption->GetValue());
      mainModule->SetSnapshotFile(logOption->GetValue());
    
    The implementation below that is quite simple and only important to
    module-developers:
    * BrModule will have a virtual function called Snapshot(), which will be
    overloaded by all brat classes inheriting from BrModule. The BrModule one
    only outputs the class type, name and title.
    
    * Every module has its overloaded version of Snapshot(), and prints out
    all settable parameters that it has control over in addtiton to the name
    of the setter function. An example, from BrTileRdoModule:
    //_________________________________________________________________
    void BrTileRdoModule::Snapshot(ofstream &f, Option_t* option)
    {
      // Output info on all settable members to file
      // Must be overloaded by all modules!
      TString opt(option);
      opt.ToLower();
    
      if (opt.Contains("e"))
        f << "Module: " << IsA()->GetName() << " " << GetName() << " " <<
    GetTitle() << endl;
    
      BrMultRdoModule::Snapshot(f);
      f << PrintIntMember("AdcGapLimit",fAdcGapLimit) << endl;
      f << PrintIntMember("SaturationChannel",fSaturationChannel) << endl;
    
      if (opt.Contains("e")) {
        f << "# CVS info: $Revision: 1.19 $ $Date: 2002/09/19 22:27:04 $
    $Author: sanders $" << endl;
        f << endl;
      }
    
    }
    
    (PrintIntMember and similar are functions of BrModule...)
    
    Note that it outputs info like class name and CVS stuff iff it is the
    end-level class (option "e"). It also calles Snapshot for BrMultRdoModule,
    which it inherits from.
    
    * In BrMainModule::Main, there is a new small addition just after booking
    the histograms that looks like this:
      // Make snapshot logfile, return if this fails
      ofstream fLogFile(fSnapshotFile.Data());
      if (fLogFile.is_open()) {
        Snapshot(fLogFile,"e");
        fLogFile.close();
      }
      else {
        Error("Main", "Couldn't open snapshot logfile");
        return fStatus;
      }
    
    and its version of Snapshot() which looks like this:
    //____________________________________________________________________
    void BrMainModule::Snapshot(ofstream &f, Option_t* option)
    {
      // Output module information to log file
      // for each module in the pipeline
      TString opt(option);
      opt.ToLower();
    
      TIter    next(fModuleList);
        BrModule *object;
        while((object = (BrModule*)next()))
          object->Snapshot(f,option);
    
    }
    
    i.e. it simply goes through its list of modules and calls Snapshot() for
    each one with the end-level option, and they in turn call Snapshot() for
    any parent classes without the end-level option.
    
    A test bratmain script which contains only the BrTileRdoModule then looks
    like this:
    
    ---------------------------------------------------
    Module: BrEventIO BRAHMS ROOT IO File eventInput
    
    Module: BrTileRdoModule MultTile MultTile
             AdcGapLimit                4096
       SaturationChannel               30000
         ThresholdFactor            5.000000
           OutlierMethod                   3
            SingleAdcLow            0.000000
           SingleAdcHigh          500.000000
           SingleAdcComp           10.000000
             AdcGapLimit                4096
       SaturationChannel               30000
    # CVS info: $Revision: 1.19 $ $Date: 2002/09/19 22:27:04 $ $Author:
    sanders $
    
    Module: BrEventIO BRAHMS ROOT IO File ouputModule
    --------------------------------------------------
    
    I'll get rid of the BrEventIOs in the next implementation - they shouldn't
    be there I think (see below for why).
    
    Also note that two of the parameters occur twice - that's because
    BrTileRdoModule has two setters that are identical to its parent class
    BrMultRdoModule. This framework also incourages cleaner coding ;-)
    
    The point of this excercise is two-fold:
    * First of all we get proper documentation of all relevant parameters for
    a given data reconstruction. This has been missing for a while and caused
    problems for both me and several others I have talked to.
    * Secondly, we get an easy way of recreating old bratmain scrips. By
    adding one more function e.g. to BrMainModule, it is easy to just read in
    this script, autogenerate all module with the proper parameters set and
    run the reco with the same conditions as before. This sounds to me like a
    nice feature, and I'd like to implement that too in this process. This is
    the reason why I don't want the EventIOs in the output - I only want the
    user-added modules to the basic bratmain script!
    
    That's the main outline - it's a bit sketchy, but I wanted to send
    something before I leave BNL (right about now...). I won't proceed on this
    until thursday, so please take some time to think this over before
    replying. What I'm offering to do is make the main framework for this and
    also add Snapshot() to the most frequently used modules, filters, packages
    etc. I can't promise I'll do them all as there are 101 modules in BRAT
    (and then filters, packages,... come in addition), but I'll try to do most
    of it. Timescale: Done before xmas if no big problems arise. The main
    framework is already implemented. If I run into trouble or we decide on a
    radically different approach then I need some more time... (And I have a
    hand-in exam in "Philosophy of Science" next week, but hey...)
    
    Ok, I'm off to the airport. Ping :-)
    
    --
    Bjorn H. Samset                           Phone: 22856465/92051998
    PhD student, heavy ion physics            Adr:   Schouterrassen 6
    Inst. of Physics, University of Oslo             0573 Oslo
                                  \|/
    ----------------------------> -*- <-----------------------------
                                  /|\
    


    This archive was generated by hypermail 2.1.5 : Tue Dec 10 2002 - 15:03:17 EST