Re: [BLAST_ANAWARE] spud disks

From: Chris Crawford (chris2@lns.mit.edu)
Date: Mon Jun 21 2004 - 18:42:10 EDT


hi tancredi & chi,

Chi Zhang wrote:

>>In addition, I propose to just leave "flr" data and just scrap the "lr"
>>data. The only application I can see for "lr" data is the wch efficiency
>>which anyways requires more sofisticated tof-filtering which can be done
>>straight from dst. Any problems ?
>>
>>
>
>Hi, DST does not contain events with no WC tracks, so it would be
>quite difficult to do WC efficiency from that. expanding DST to include
>all triggers would probably be more expensive than lr.
>
>
i would say to leave 'lr' the way it is.

>Maybe a stipped lr ntuple with fewer entries? but I am not sure how many
>entries we can strip off. first thought would be getting rid of all
>NC/LADS/BATS and some of the epics/scaler entries. but people may want to
>use them for trackless events, for example before BATS hits are
>incorporated into tracking therefore into DST. And software wise, this
>will cause different entry structures in lr and flr so it could happen
>that analysis that work with flr would not work with lr.
>
>One of the problems with recrunched lr/flr files is that the ntuples are
>duplicated. so after 1st recrunch, lr and flr doulbes in size. below are a
>few senarios lrd would accept:
>
>1st: all DST, lr, flr files in $ANALDIR:
> backup dst, lr, flr, flrpm into dst_1, lr_1, flr_1 and flrpm_1 in
> the same root files
> very expensive in disc space.
>2nd: DST, lr in $ANALDIR, flr file not found in $ANALDIR
> backup dst, lr into dst_1, lr_1, create flr, flrpm from scratch
> flr root file will be about same size as the original, dst and lr
> will double in size
>3rd: DST in $ANALADIR, lr, flr file not in $ANALDIR
> backup dst into dst_1, create lr, flr, flrpm ntuples from scratch
> all trackless triggers in lr will be lost, efficiency study may be
> compromised
> only dst file will increase in size.
>
>I think the 3rd approach should be avoid unless the original lr files are
>backed up and people do not intend to use the new lr files for efficiency
>studies. This seems to fit current recrunches but I remember Michael has
>some problem recrunch without lr files in $ANALDIR.
>
>To play it safe with less demand on storage, try the 2nd way. I can try
>again to play with lrd, but I admit I am not very good at handling root
>files.
>
>
>
one way to cut down on disk space would be to substitute 'flrpm' for
'flr'. of course, people wanting only one track (inclusive) would have
to make their own filter from 'lr'.

it would be nice to have an option in 'lrd' to read from $ANALDIR and
write to a different $OUTDIR before any more recrunches from dst. i
already tried to do this once unsuccessfuly, but i think it's just a
matter of spending more time on it.
--chris

>Chi
>
>
>
>
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST