Hi BRATs,
I've updated BRAT and tagged it:
CVS TAG: BRAT-1-11-0
Version: 1.11.0
Changes are:
* BrModuleContainer:
This class now inherits from BrModule, so that BrModuleContainers
may be added to BrModuleContainers (nested containers!!!!).
Also, the methods Begin and End are implemented (recursively calls
Begin and End on all contained BrModules and BrModuleContainers).
My main motivation for having nested containers, is so tht we may
design 'module packages' like say a 'Tracking Package' or a 'Vertex
Package', and these could then be plugged into an application. E.g.,
one may have a 'Tracking Package', looking something like (never
mind the names, they are probably wrong):
class BrTrackingPackage : public BrModuleContainer {
BrClusterFinder* fClusterFinder;
BrClusterFixer* fClusterFixer;
...
}
BrTrackingPackage::Init() {
fClusterFinder = new BrClusterFinder();
fClusterFixer = new BrSmartClusterFixer();
...
fModuleList->Add(fClusterFinder);
fModuleList->Add(fClusterFixer);
...
}
BrMainModule* mainMod = new BrMainModule()
BrTrackingPackage* trackPack = new BrTrackingPackage;
mainMod->AddModule(trackPack);
Heck, this could even be done using scripts in combination with
BrMainModule and TestMainModule.
* BrMainModule:
A singleton BrModuleContainer that is intended as the top most
module container for any given job, be it analysis, reconstruction,
calibration, etc. It has some static members which can be used as
flags for ending runs and event loops.
Let me remind you how a BRAT application will execute:
+-------------------+
| Set up job things |
+-------------------+
|
+------------------------+
| Initialize job |
| [BrMainModule::Init()] |
+------------------------+
|
no o------------------------o
+-<---| More runs to process ? |---<----------+
| o------------------------o |
| | yes |
| +-------------------------+ +-----------------------+
| | Initialize for run | | Finish run |
| | [BrMainModule::Begin()] | | [BrMainModule::End()] |
| +-------------------------+ +-----------------------+
| | |
| o-------------------------o no |
| +--| More events to process? |-->----------+
| | o-------------------------o
| ^ | yes
| | +-------------------------+
| +--| Process event |
| | [BrMainModule::Event()] |
| +-------------------------+
|
|
+--------------------------+
| Finish job |
| [BrMainModule::Finish()] |
+--------------------------+
(For lack of proper graphics, 'o' corned boxes are decisions, while
'+' boxes are process). Each of the process is taking care of be
BrMainModule, but the decisions are left to the
application. However, BrMainModule provides features to help out the
application (and modules) making these decisions. The static methods
void BrMainModule::StopRun()
void BrMainModule::StopJob()
is provided so that modules may terminate a loop level. The static
methods:
Bool_t BrMainModule::NextRun()
Bool_t BrMainModule::NextEvent()
is provided for the application or modules to test if the next
run/event is to be processed. These features are fully expoloited in
the TestMainModule application and TestModule module (see below). It
is my hope (and believe) that this class will provide the foundation
for any application using BrModules. IMHO, the TestMainModule is a
very good example of how powerful this class really is.
* test/TestMainModule, test/TestModule test/Config.C
This is an example of using nested BrModuleContainers and
BrMainModule (as outlined above). The class TestModule is a dummy
module that does nothing interrestin, other then showing some
features of BrMainModule.
However, it has another, IMNSHO, powerful feature for runtime
configuration. In the very beginning of the program a script (some
call it a macro, but that's misleading) is executed (Config.C). In
that script, the user can set up the job s/he wants to run. That is,
add BrModules, BrModuleContainers, and/or Packages to the
BrMainModule. This program uses the static methods
void BrMainModule::StopRun()
void BrMainModule::StopJob()
Bool_t BrMainModule::NextRun()
Bool_t BrMainModule::NextEvent()
For the job flow control. As such, it fills the gabs in the above
flow diagram that BrMainModule left i.e., the decisions and the
initial set up of the job (via Config.C).
Currently the name of the script is hardcoded, but the program could
trivially be expanded to take command line arguments (using
BrAppOptionManager) so another script may be used.
I'd like to encourage people to exploit the features of BrMainModule
and the program TestMainModule. I believe it's very VERY powerful, and
I do believe this is the way we should do analysis, reconstruction,
etc. applications.
>From the above, it should be clear that these changes warrented a
minor version bump of BRAT.
Any comments, suggestions, flames, etc are welcome.
Yours,
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 : Tue Sep 26 2000 - 16:52:30 EDT