The code has successfully analysed a full file of 1039 laser events (~ 40 - 45 tracks each), a full file of ~3000 cosmic ray triggers, and a little file of 44 events with just the central membrane pattern illuminated. This required that the code recognize "ROSIE_RESET" and "SLOW_CONTROL" records that sometimes appear in the event stream and that it skip events where one or more of the TPC_EVENT tables are missing. It has not been used on every event stream recorded, so new problems may arise. The quick compile cycle and the fact that the script and the compiled code use the same language and the same variables has been invaluable for debugging.
The event display in tst.kumac produced xy, yz, and xz views of each cosmic ray event and each of seven slices of each laser event (the lasers produce 6 or 7 track patterns at each of 6 z values and a pattern of lines drawn on the central membrane is illuminated). tpctest.C produces a ROOT 3-d plot that can be rotated to any point of view. When run on NT there is a 3-GL 3d plotting option that gives also zoom control. The event plot is also improved by using different plotting symbols to represent the track each hit has been assigned to as well as color coding the hits and line representing the track they are on. Currently ROOT is limited to about 11 symbols and maybe 50 distinguishable (your mileage may vary) colors. It would be nice to expand this. The TPC sectors are plotted as ROOT (GEANT?) TPGONs which are inserted into TNodes. I don't understand this structure yet but it works.
The final ntuple in tst.kumac was accomplished by joining columns from five different tables into a new table (using STAF TOP/SORT and FASTJOIN) which was then transferred into a PAW ntuple file. This is done in the St_tpctest_Maker::tst_joiner() function by a brute force loop over all the relevant tables. Some saving of CPU could be accomplished by being cleverer in this routine but the current time is less than half a second/event on the systems we've tried it on (Sun/Solaris, WINNT, and Linux).
St_laser_Maker slavishly reproduced the tst.kumac behavior. For tpctest I have dumped from the final ntuple some things I never found useful and added some others (like event number) that I hope will help. It is rather trivial now to redefine the ntuple and recompile.
tpt_sts is pretty efficient at finding the CR and laser tracks at full length. Currently tpt is pretty good at the CR tracks and laser tracks that make 10 to 40 degree angles to the radial direction. Tracks along the radius and at large angles are usually broken into pieces, if they are found at all. There is also a tendency for tpt to fail to join tracks from the inner and outer sectors. Since these are real data signals I think this would be a good sample to use to improve the tpt algorithms. Even better would be some new tpc test data.
I began this effort with little familiarity with C++. It is possible to make a good bit of progress and remain largely ignorant of the OO aspects of C++. This is unfortunate in a way. It is however not possible to get very far without learning some C++. I could never have survived without the help of Yuri and Valery, but sometimes I was able to find and fix my problems myself. I don't want to give the impression that the transition to ROOT is pain free, but it has had some satisfying moments.
The code in St_tpctest_Maker.cxx may not all be pretty but there are examples there of how to do a lot of things in the STAF-ROOT setup. For example to access the tpc track and hit tables:
St_DataSet *data = gStChain->GetData();
St_DataSetIter next(data);
St_tcl_tphit *hits = (St_tcl_tphit *) next("data/tpc/hits/tphit");
St_tpt_track *track = (St_tpt_track *) next("data/tpc/tracks/track");
tcl_tphit_st *hit1 = hits->GetTable();
Int_t nhits = hits->GetNRows();
tpt_track_st *track1 = track->GetTable();
Int_t ntracks = track->GetNRows();
At this point the following code loops through all the rows in the hit
table
tcl_tphit_st *h = hit1;
for (i = 0; i < nhits;i++){
h++;
}
with h->track as a pointer to the track assignment for the hit, for example.
Please look at the code and ask me why? (and why not?).
The track plotting is not helped by the fact that all the angles are now in units of degrees. C++ has sin, cos and tan functions for radian arguments only, as far as I can see. Its hard for me to imagine a use for the track parameters that goes better with angles in degrees.
Most of the time this code relied on a base that existed only in the dev branch of the STAR code library. It currently runs in SL98g which is starnew, soon to be starpro. It has run lately on Solaris and Linux. Linux (gnu g++) is a little more particular about C++ errors. It choked on a bug in tcl_get_row_seq where the code was trying to read the tpmcpix table for an index out of range (no check on Solaris?). Unfortunately the mixed compiler situation on Linux (We use PG fortran and GNU C++) means we don't seem to have a usable debugger there. dbx works pretty well on Solaris. I haven't played enough with workshop to be comfortable yet.