Comments below... > -----Original Message----- > From: owner-brahms-dev-l@bnl.gov [mailto:owner-brahms-dev-l@bnl.gov]On > Behalf Of Flemming Videbaek > Sent: 5. juni 2002 16:11 > To: brahms-dev-l@bnl.gov > Subject: Re: reduced data and drift velocity calibrations > > > > Two comments to this discussion: > > It has ben agreed that in general we should remove all event files > generated in previous first passes > i.e. generating only local tracks and copying other relevant > datastructures. > This has two positive effects > cleaning up disks and making it clear that files found there are the most > valid. > Could we possible agree on a somewhat more specific setup that > done at this > moment > the data14 is organized as > /brahms/data14/data/reduced/ - jsf > - log > - reduced/ R<runno> > Could the data/reduced be name eg. data/pass0_2001 or > data/level0_2001 - I > am open good ideas for consistent > naming such that we can see these are the official passes and be > distinguished from files like > dataxx/igb/R... data/pp/Rxxxx etc. I would encourage people who actually > generated files that they know are not optimal i.e. no good gets > deleted so > we can have a coherent effort. So far we have used the convention ../Rxxxx/log ../Rxxxx/seq/run00xxxxseqnnn.root for the "reduced" data, that is, data containing local tracks from tracking detectors with all other info copied to into the file. The next step is to make files containing global tracks, and here the convention is ../Rxxxx/global/gtrxxxxseqnnn.root finally, we make the dst (data summary tree!?) ../dst/fs/dstxxxx.root ../dst/mrs/dstxxxx.root I don't know if this naming scheme is optimal, but it does have the advantage that there is no underscore in the name :-), and the names are reasonably descriptive. The only place one could grab the wrong file would be if one wanted fs and took mrs dst. I agree that the obsolete data should be deleted, but right now some of it is being used to produce calibrations of (e.g.) drift velocities. It is my (unreasonably optimistic, I am sure) hope that all of the old data is gone by the end of this week, and most of it is replaced by *new and improved* data files. > > Could we also save the officiual production scripts that now resides in > peoples private directories e.g. create for proper documentation > a brahms_app/reco_apps/pass0_reduce/ and have in CVS, together with any > other setup needed. We can then expand this for the calibration > scripts etc. The scripts we are using are in brahms_app, as described in Djamel's analysis note. I agree, however, that it would be good to have them in a more 'common' location. > > -- Specific request for the reduction script > Djam, could you please add the following copy objects > " DigTof TMRS" > "DigTof TMrsB" > "DigTof TMrsF" > > They are of course only relevant for the PP running so nothing has to be > redone. > > -- > Second comment: > I will like to have some discussion on the Vdrift calibration on T2(T1). I > have seen the plots from > Pawel that shows a small difference between the Y(T2) and > projected Y(T3) to > T2 in the order of 0.01 in Vdrift. > It is not priory obvious what is the better value being sensitive to > slightly different effects (the projections to the > fibers depends on the . One should though keep in mind that projecting to > in particular T1 is a long projection over 6 meters - > this couls be checked by looking at the T3 projection to the fiberplane(s) > and getting the local Y for the T3 tracks that has > signals in the fibers just as for the T1,T2 local tracks. > Certainly one lesson from the Tpm2 vdrift from the fibers was the > front/back > gave different values. It is a good idea to check the T3 tracks directly against the fibers. As far as I know this has not (yet) been done. Pawel has checked T3 vs T4 and T5 to get an idea how confident we can be in the T3 projections, and I am sure he will soon share these results with all of us. It seems to me that the T3->T2 is OK, and for runs where the vdrift has been found using both T3 and fibers the results are consistent. The reason for developing the T3 method is that it can be used for the entire run, whereas the fibers can not. It is true that there are uncertainties associated with projecting T3 tracks to T1, and this is being taken into consideration. Finally, it should be noted that the point of this work is to more densely populate the data base, and it is done more quickly using T3. It should also be pointed out that the US beat Portugal (3-2) this morming in an absolutely beautiful football match! Cheers, Ian > > > ------------------------------------------------------ > Flemming Videbaek > Physics Department > Brookhaven National Laboratory > > tlf: 631-344-4106 > fax 631-344-1334 > e-mail: videbaek@bnl.gov > ----- Original Message ----- > From: "Djamel Ouerdane" <ouerdane@nbi.dk> > To: <brahms-dev-l@bnl.gov> > Sent: Wednesday, June 05, 2002 5:11 AM > Subject: reduced data > > > > Hi all, > > > > /brahms/data14 is 100% full because of the reduced data stored in > > /brahms/data14/data/bad > > > > This dir is named bad because some (not all) of the data was > reduced with > > wrong detector parameters (e.g. TPC stuff completely obsolete). > > > > Are there some people using this data ? As far as I know, the FS part > > should be ok although I don't garanty it. If no one's using it, I'd like > > to remove it. Some new TPC calibrations were done these last 2 days, > > implying that the data should be reprocessed. > > > > Djam > > > > > > -- > > Djamel Ouerdane ------------------------------------------o > > | Niels Bohr Institute | Home: | > > | Blegdamsvej 17, DK-2100 Ø | Jagtvej 141 2D, | > > | Fax: +45 35 32 50 16 | DK-2200 Copenhagen N | > > | Tel: +45 35 32 52 69 | +45 35 86 19 74 | > > | http://www.nbi.dk/~ouerdane | > > | ouerdane@nbi.dk | > > o---------------------------------------------------------o > > > > >
This archive was generated by hypermail 2b30 : Wed Jun 05 2002 - 10:42:35 EDT