_ Data in /net/data/4/Analysis/data is "fine" but has no recalibrated tof
timing. However it is also clear as aron says that sometimes the init.C
check does not catch all "broken" runs. We also find the same problem !
_ run macro.C closed as chi suggested.
_ missing ADC unfortunately result in missing lr data, as I found
out yesterday. This is my mistake since sometimes I am just too
tired to argue definitions. Use Raw/check_adccheck.C to check if
there are missing adc in the RAW data. It can be quickly modified
for neutrons.
_ for ee'p and ee'n you should be able to do your analysis
without ADC cuts, as was shown in the past. Then you can retain
the full statistics. That is why I redid all runs from wednsday on
_ Another important issue is the recrunched data. YOu should not use paths
such as /net/data/8/Analysis/data(/v3_2) or /net/data/4/Analysis/data/v3_2
There is a problem with missing runs (due to either nfs or permission
problems or just confusion since it turned out that me and michael
started mv/cp the data at the same "time")
_ Only the recrunched in (e.g) /scratch/bud19/blast/Analysis/data/v3_2
is ok. This you can confirm by
_ checking that they have the same charge of the first pass data
in /net/data/4/Analysis/data
_ they also have the same number of lr events (since lrd does not
cut events out)
_ we just found a big difference between /net/data/8 and
/scratch/bud19 for hydrogen runs
_ othjer recrunched data in /scratch/bud20, /scratch/bud21...
P.S.
Note: there is no blanket ADC cut for all tofs for either proton or
electrons, so I dispute adc cuts unless they are done tof by tof.
P.S.
It was noted by genya first that some runs miss the charge. Typically the
dst file is much shorter in size. Out of 12 such runs, just reanalyzing
them gave a valid dst files. The problem is either in nfs or human error
or else. It did not seem to be very widespread I think I only found ca~20
such cases over few thousand runs (by comparing the lr/dst files size
ratio).
-- ________________________________________________________________________________ Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124 research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^On Sat, 24 Jul 2004, vitaliy ziskin wrote:
> Aaron, > Can you update a runlist accordinly. I don't think that no-ADC data runs > are particularly bad. I'm more worried about this no-Charge business. > Cheers, Vitaliy > > Aaron Joseph Maschinot wrote: > > >b/c of the recent "no-ADC" data runs, i've been looking through the data > >files. i've found some bad things... > > > >1) karen estimated that the no-ADC data runs started at run 9243 and go > > through run 9263. however, runs 9241 and 9242 both have something > > wrong with them, too; the vector polarizations from these runs are > > just wrong. maybe the ADC was "sort of" signaling in these runs. > > anyway, for the present, i think we should not include them in the > > analysis. > > > >2) more scary is the fact that some files appear not to be recording > > charge data. up to just a couple of minutes ago, i thought that root > > would issue a warning if no charge was found. however, run 9232 has > > no charge in it but root doesn't give any warning about this fact. if > > other such "no-charge-but-root-doesn't-mind" files exist, then they > > will clearly have a BIG impact on polarization. > > > > for example, the vector dilution of runs 9230 9231 9233 9234 is > > "normal" (around 0.57 or so). however, if i include run 9232 in the > > listing (as it is listed in pol.log), the dilutions become -0.137 and > > 0.062!!! admittedly, i haven't been looking at each data file, > > one-on-one, in order to see if there is anything wrong with it (i.e. > > no charge, no ADC, etc.); it's kind of hard to do that with 200-300 > > files. but, clearly, even one such bad file can mess up three others > > drastically. > > > >3) runs 9098, 9099, 9101, and 9102, though listed as "good" files, all > > have no ADCs. the log-book says that the right-sector WC's didn't have > > any HV around this time. maybe this somehow affected the runs. > > however, these files' charges have been being taken into account for > > total charge to normalize by. > > > >i'm going to update pol.log. however, it seems to me that a file-by-file > >check is necessary. maybe a scanning short scanning program could be > >written that will, for each file, make sure that it has charge, TDCs, > >ADCs, etc. it seems that, do to the large number of incoming files, it > >would seem appropriate for the shift taker to run such a file (else > >everyone else who does analysis will have to individually check ALL the > >files). > > > >aaron > > > > > >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST