hi,
first, i am confident that we will be able to do real-time crunching
in january when we start taking data again, especially if we get our new
spuds.
while it is important to have charge summaries per fill and run, i
think it is also necessary to have the charge during the last scalers
cycle recorded in the scaler tree, and integrate this right during your
analysis, like tancredi said, so you can cut on epics/scalers conditions
in your analysis.
Tancredi Botto wrote:
>>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
>
the only problem we had was with cint (root's c++ interpreter).
TStrings can be realllll long.
but anyways, i would not recommend TStrings for future analysis; there
are two more efficient alternatives.
>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...)
>
i agree, it makes more sense to filter out your own ntuple from the dst,
and then analyze that.
>
>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