Re: TOF MuDST definition (Re: MiniDst need FTPC information)

Date view Thread view Subject view Author view Attachment view

From: W.J. Llope (llope_at_physics.rice.edu)
Date: Fri May 09 2003 - 10:27:27 EDT

hi guys - nice work here... can i suggest you folks
summarize the status of all this at next week's TOF phone
conference?

(i happen to be very eager to start working with
'match ntuples' from TOFr...)
also some quick comments below...
thanksm cheers,
        bill

At 1:19 AM -0500 5/9/03, Frank Geurts wrote:
>dongx_at_mail.ustc.edu.cn wrote:
>> Hi, Frank:
>> Dr. Wu and I have modified the MuDstMaker code for TOF microdst data.
>> We have two versions now :) You may look at the directory
>> /star/u/dongx/work/TOFr/MicroDst-bak and MicroDst-bak1
>> In the first version, MicroDst-bak/ , we assume the StTofHit in StEvent
>> has been updated ( just in StRoot/StEvent ), and we fill them in the
>> analysis maker (StTofrSimMaker, which should be renamed actually), and
>> then dump them into TCloneArrays in StMuDstMaker.
>
>Hi Xin and Jian,
>great work ... but, you seem to loose the relation between the
>associated track and the StTofHits while storing the data. Which makes
>me wonder whether the StTofHit (or Slat/Cell for that matter) is really
>suited to be literally passed on to the muDST: if we can't store a
>pointer to the associated track then we are better of setting up the
>PIDtraits for tof (as a branch of primary track) and filling them with
>as much data as we have available. To first order that would be adc,
>tdc, tray, cell/slat, (local) hitposition and depending on whether we
>have calibration available or not non-zero values for the other members
>of StTofHit.

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]
> > 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?

regards 

-- 

  W.J. Llope, Ph.D.                      Res. Assoc. Professor
  T.W. Bonner Nuclear Laboratory         phone:  713-348-4741
  Rice University, MS-315                fax:    713-348-5215
  6100 S. Main St.                  
  Houston, TX 77005-1892            
             e-mail:     llope_at_physics.rice.edu
             WWW home:   http://wjllope.rice.edu/default.html

--
                        
Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:41 EDT