Hi all,
I've made a new revision of BRAT.
Version: 2.0/1
CVS Tag: BRAT-2-0-1
Hmm, I seem to have left out of the README file how to make revision
bumps. Well, it's basically as described in the BRAT guide, except
you shall not edit the file brat-config, but rather configure.in. The
line in question is
AM_INIT_AUTOMAKE(brat, 2.0.1)
And then you ofcourse need to tag the CVS (as explained in the BRAT
guide). I'll put that into the guide soon. What I also failed to
say, is that idea's, suggestions, bugs, contributions and so on for
the BRAT guide are very welcome.
Changes in BRAT 2.0.1:
2001-06-29 Christian Holm Christensen <cholm@hilux12.nbi.dk>
* configure.in: New revision
* modules/calib/tof/Makefile.am, modules/calib/tof/LinkDef.h, modules/calib/tof/Include.h, modules/calib/tof/BrTofTimeOffsetCalModule.h, modules/calib/tof/BrTofTimeOffsetCalModule.cxx, modules/calib/tof/BrTofTdcOffsetCalModule.h, modules/calib/tof/BrTofTdcOffsetCalModule.cxx, modules/calib/tof/BrTofSlewingCalModule.h, modules/calib/tof/BrTofSlewingCalModule.cxx, modules/calib/tof/BrTofDeltaDelayCalModule.h, modules/calib/tof/BrTofDeltaDelayCalModule.cxx, modules/calib/tof/BrTofCscintCalModule.h, modules/calib/tof/BrTofCscintCalModule.cxx, modules/rdo/BrTofRdoModule.h, modules/rdo/BrTofRdoModule.cxx, modules/pid/BrTofPidModule.h, modules/pid/BrTofPidModule.cxx:
Imported TOF classes from Djamel
That is, I imported some new version of the TOF classes, removed
BrTofTimeOffsetCalModule (now BrTofTdcOffsetCalModule) since Djamel
said it isn't and shouldn't be used. Notice the addition of
BrTofPidModule.
Djamel just left for vacation (for 2 weeks) and I guess he can say
more when he's back. In the mean time, please feel free to try out
the classes. I believe Ian will try write a note - but it's not
confirmed.
The classes still uses BrDetectorTrack, but I guess they should really
use BrTrack instead, since that's what you'll get from the TPC and DC
code soon. Also, we need a discussion on how to most effectively tie
together BrTracks, pid (from Tof, C1, and RICH), verticies (both
primary and secondary), track matches and so on. I could imagine
something like
class BrGlobalTrack : public TObject {
private:
TObjArray* fDataObjects; // Array of tracks, hits, ...
public:
...
};
So that one would, starting with track matching, put more and more
objects into the internal array of BrGlobalTrack. So each
reconstruction module in the spectrometers would add a new object to
a BrGlobalTrack (in pratice, it'd be the matching module that sets up
such an object). This, I believe reflects the structure of the actual
experiment quite well.
In the end, one could do a pass over such an object to get a physical
particle:
class BrParticle : public TObject {
private:
TLorentzVector fMomentum;
TLorentzVector fProductionVertex;
Float_t fCondfidence;
BrDetectorList fDetectorsUsed;
public:
...
};
by extracting the best possible set of values for Px, Py, Pz, E (m2),
Vx, Vy, Vz, Vt(?) from the elements of the array and assign some sort
of confidence level to the set.
Also, I think we could expand BrDataObejct to contain a BrDetectorList
(4 bytes), so that for each element in BrGlobalTrack::fDataObjects we
know which detector(s) produced that object. A match segment would
then belong to a magnet or vacuum (T2 to T3 matching).
The reason for the BrParticle::fProductionVertex member, is that you
may find, for example by swimming back through D1, that the track
really points to something not close to the primary collision vertex,
and so in some way, it'd be nice to be able to keep that particle, but
make sure that it's obvious that it's not from the collision vertex.
We'd also ofcourse have some data object(s) that describes the global
characteristics of the event, for example
class BrEventSummary : public TObject {
private:
Int_t fRun;
Int_t fEvent;
Float_t fCentrality; // From Br[Mult|Tile|Si|BbZdc]Cent
Float_t fCentralityConfidence;
Float_t fMultiplicity; // From Br[Tile|Si]Rdo
Float_t fMultiplicityConfidence;
Float_t fNParticles;
BrDetectorList fDetectorsOn;
...
public:
...
};
This could be split up into seperate classes ofcourse.
I think the two classes BrParticle and BrEventSummary are ideal for a
DST (PhDS) TTree storage.
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 2b30 : Fri Jun 29 2001 - 11:45:50 EDT