From: Kris Hagel (hagel@comp.tamu.edu)
Date: Tue Dec 10 2002 - 16:17:59 EST
Bjorn,
I am not following your suggestion to think a long time before answering.
I think this is an interesting way to attack this problem. One thing I
would add though (without thinking a long time, but probably even if I
do) is that I am frequently curious about input and output data files of
particular jobs. In particular, I frequently see a particular reduced
file for a particular system and wonder what the parameters were for the
data that went into it. That is just the information you are proposing
to get rid of with the elimination of BrEventIO etc. I would say keep
it or treat it in a special way by having input and output of the
bratmain job.
Anyway, That is my two cents worth (without thinking too much)
Kris
Bjorn H Samset wrote:
>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 - 17:11:22 EST