From: Frank Geurts (geurts_at_rice.edu)
Date: Fri May 09 2003 - 11:03:54 EDT
W.J. Llope wrote:
> hi guys - nice work here... can i suggest you folks
> summarize the status of all this at next week's TOF phone
> conference?
no problem ... although i repeatedly seem to have a hard time dialing in
on time :)
>
> (i happen to be very eager to start working with
> 'match ntuples' from TOFr...)
> also some quick comments below...
> thanksm cheers,
> bill
[...]
>
> hi guys
> these are the variables i would ask for..
>
> (globals)
> run
> event
> trgword
> magfield
> zvtx
> refmult
> nprimary (total, not just that in our acceptance)
> ctbsum
> zdcsum
>
> (from tof raw data)
> cell ID
> cell ADC
> cell TDC
> pVPD ADC[6] (the 6 high range ones)
> pVPD TDC[6]
>
> (from tracking)
> p, pt, eta
> nfitpoints
> chi2
> dedx
> ndedxpoints
>
> (from matching)
> s
> Zhit
> "hitprof" or equivalent
> matchflag
>
> [snip]
all non-tof variables are in the STAR MuDST per definition (or can
easily be derived from it). We only need to add in the tof variables
which for starters would be id, adc, tdc but should already contain all
the hooks we've defined in the new StTofHit container.
The STAR MuDST has the huge benefit of containing all the other tracks
and STAR physics data which makes it a far more attractive platform to
do any analysis on than e.g. the match ntuples we have used for tofp data.
>
>> > In either of these two, we need the analysis maker to give sufficient
>>
>>> information according to the coming StTofHit, which means data
>>> should be
>>> calibrated already before filled into
>>> StTofCollection/StMuTofCollection.
>>
>>
>> like i mentioned earlier, calibration is not necessary as long as we
>> don't loose the relation between associated track and slat/cell data,
>> which is something we will be needing anyway!
>
>
> i absolutely agree.
> i would vote for not building any stop- or start-side calibrations into
> this code just yet. the matching is hard enough as it is and
> the resulting match ntuples are plenty capable (if they include
> at least the variables above) of supporting
> all the calibraitons and most of the physics analyses too... once we've
> built up a good concensus in the wider TOFp+TOFr group on how to perform
> all of the corrections, we can start moving routines up a level into this
> matching code to make our life simpler... how does that sound to you guys?
>
For the MuDST we will have all the relevant variables available and fill
them if we feel comfortable doing so or leave them empty. The bottomline
is that this particular approach allows us to only rerun the event.root
files and rebuild the MuDST with the new TOF pid traits. Of course
nothing keeps us from distilling an even compacter ntuple out of the
MuDST, which would be much alike the tofp-match ntuple.
One thing that we do need to be sure about is the matching routines
because these will have to run in the "production" phase. For d+Au i
don't think we need to be worried about any occupancy issues but for
Au+Au we do need to check some issues that have come up recently.
cheers,
Frank
This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:41 EDT