From: Bjorn H Samset (bjornhs@rcf2.rhic.bnl.gov)
Date: Thu May 29 2003 - 10:36:46 EDT
On Wed, 21 May 2003, Claus O. E. Jorgensen wrote:
<Warning: Long email ;->
>
> Hi analysers,
>
> I think it's time we all agree on a standard dst and I can see it's on
> the
> agenda of the collaboration meeting, so maybe we should start the
> discussion. I would be nice to have a framework (that can be used for
> data
> from all collisions systems) ready for the meeting.
I couldn't agree more - sorry it took so long to reply to this. I guess we
have to settle for trying to decide on a framework AT the meeting...
Anyway, here are some thoughts from me.
> As I see it we have to figure out a couple of things:
>
> - (the easy part) What should the DST contain? What information do we
> need from what detectors? I think the bdst is pretty close to what we
> want - maybe it needs a few modifications for the d+Au and p+p data.
I agree what's in bdst is good, and after Kris' recent additions it's
usable for pp and dAu as well. I don't know if C4 and TOFWII are there
yet, but they should just be added in the standard way. What I really like
about bdst as a base framework is that it really contains (almost)
everything that the global tracking/pid step does - i.e. there are no cuts
done bewtween the gtr and bdst files. It may sound obvious, but let's make
sure it stays that way.
So far the only thing I've really missed in bdst, as you note below, is
run information like scaledowns etc. You also wrote
> - How should we organize the data? I like the tree structure but I miss
> the run information.
and Pawel recently replied:
> Why not create a new class called (e.g.) BrDstEvent and save the
> respective objects as a single leaf in the tree structure. BrDstEvent
> could contain header section to keep
> global information (like event number) and array-type objects to keep
> information about tracks (particles). We can also split BrDstEvent into
> a few sub-classes (according to the type or the meaning of variables)
> and keep them in the different branches.
I've tried this approach, and it actually works very well. Have a
look at
brahms_app/bhs_app/flap
for the base part of my framework. I'll show it off properly in Krakow,
but here is the main structure. It's a post-bdst
framework, meaning that it works on bdst and does the pid just like
bdstMrsAna and its relatives do. It contains:
- A base class called flapEvent.cxx (to note that this is a post-bdst
framework - it works on bdst and does the pid just like bdstMrsAna and its
relatives do). flapEvent.cxx has these members:
Int_t nparticles;
Double_t inelvtx;
Int_t trigger;
Int_t nevents;
Int_t runno;
Double_t mrsangle;
Double_t ffsangle;
Double_t bfsangle;
Int_t d1pol;
Int_t d2pol;
Int_t d3pol;
Int_t d4pol;
Int_t d5pol;
Int_t d1set;
Int_t d2set;
Int_t d3set;
Int_t d4set;
Int_t d5set;
Double_t scaledown3;
Double_t scaledown5;
Double_t scaledown6;
(It's currently made for pp collisions, as you can see...) Here we have
all run information + global stuff like the vertex stored for each event.
This is actually not very wastefull, because ROOT is quite good at
compressing identical information in trees.
- flapEvent also contains a TClonesArray *particles;, which is a list of
flapParticle.cxx objects, one for each IDd particle. I've combined both fs
and mrs particles here - this is of course a matter of taste.
- The main workhorse is flapPidLooper.cxx, which takes as input a bdst,
loops over it, calls the pid classes (flapTofwPid, flapH1Pid etc.) and
fills the flapEvents.
To visualize all this, there are a couple of figures in my (now a bit
outdated) analysis report on pp ratios:
www.fys.uio.no/~bjornhs/ppReport.pdf
All in all this is very much like good old bdstMrs/FsAna, except the
output is different. It's also quite efficient - I run through the entire
pp dataset from 2001 (bdst -> flap) in ~1hr, and the total filesize is
then ~350Mb. This includes enough info to redo the pid based only on the
flap files if desired. I also run my ratio analysis on all these 10M+
events (after all cuts) in ~5mins, or in under a minute for a single
setting.
My main point is that this approach is usable. It may slow down somewhat
when we include more data and tracks in AuAu (I've tried - it seems to
work fine), but not by very much. However, I'm not sure I'd like to
advocate this as a replacement for bdst. Rather, consider this structure:
1) Global tracking files, which become
2) bdsts, with no cuts, physics etc. Also, we add the run information to
bdst for each event. I don't think this will increase the file size very
much, again because root is good at compressing. We can try, at least.
3) From here on everyone is free to use their own framework. I intend to
make a more general version of flap for use here in Oslo at least - it's
worked very well for me and it makes for quick analysis - and this
(hopefully) means that we can provide a standard set of flap files for any
bdsts that we have. As I say the PID can be redone from the flaps alone,
but even so I expect that most people will in any case prefer to have
their own software at this point. (That, at least, is why I wrote flap in
the first place ;-) If anyone is interested, flaps for the pp data can be
found here:
/direct/brahms+data10/bjornhs/pp/pid_bdst/ppPidRunXXXX.root
Replacing bdst with this kind of structure is of course also quite
possible. We could, as Pawel suggests, have something of this type:
dstEvent (with global and run info)
- fsTrack (TClonesArray)
- mrsTrack (TClonesArray)
- tpm1Track (TClonesArray)
which would be just a bdst stored in a different way. The problem with
this is that it makes it (a bit) harder to add FriendTrees, which is quite
easy with a bdst. If I want e.g. the track info from TPM2 in my bdst, I
can make a module that outputs just this and add it to a prevoulsly made
bdst - which is cool, in my opinion.
Well - these are just thoughts, not really hard opinions. Currently I
favour just exanding bdst, but I'm very open to new ideas.
As Claus said: Please comment (if you are interested in the future of
BRAHMS analysis)... See (most of) you in Krakow :-)
--
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 : Thu May 29 2003 - 10:37:22 EDT