Re: [BLAST_ANAWARE] charge file feature moving out of v3 library

From: Tancredi Botto (tancredi@lns.mit.edu)
Date: Sun Dec 21 2003 - 18:27:35 EST


> Em, after Chris showed me how to save the ntuples before whole run is
> crunched, the ideal situation I have in mind is that crunch does not have
> to wait for run to end(we can do that right now with 2.96), analysis does
> not have to wait for crunch to end(new version does that). In this case,
> analysis(including some basic asymmetry analysis) could be almost real
> time.

yes yes but the point of our discussion affected also the statistics of
the "almost real time" analysis. And so far the error bar in the fitted
asymmetry is ca. 20-30%/hr of data. Then it seems almost futile to monitor
on shorter time scales. Note however that our "fit" is done over a large
range of angles. Of course we could put everything in one bin (ca 1000
events/hr/state if you flip only one state and are reasonably efficient
in taking data) after we are reasonable confident of the "shape"

> checking if the time difference between physics event and the associated
> epics/scaler is larger than 1 second will tell us if epics/scaler servers
> are running as they are supposed to.

or maybe that the ntp servers are drifting away ? I am not very happy to
rely on that part. My computer boots 6-7 hrs late most often than not and
even if I am running ntp on it I am not sure its time is always that good.
If we can do without knowledge of absolute times, better.

 

> when you enter a dst and try to select events and get the right charge
> for those selected events, I do not see other ways than loop through event
> by event. When Draw() is kicked out,
> bool cut() { return (fill>23&&fill<50)||(fill=51)||(fill>53...); }
> is the choice.

I just hope that there is not a lenght limit like it happened with
strings, TCuts, ntuple variables. Note that this year we have had ca 10000
fills. Hence the suggestion of a post-production calculated quality flag.
Again is the "large data set" management that is a bit problematic if we
stick to one dst format (the other way to do it is ot filter and reduce...)

Thanks for all of your updates....
 
> I can experiment a little with TTreePlayer, so it will parse TStrings and
> make such functions.
>



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