On Mon, 22 Dec 2003, Chris Crawford wrote:
> 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.
it is indeed the way is implemented. see declaration of TBLScalerEvent in
TBLEvent.h. the class contains 4 TMatrix:
scalr_charge_p, scalr_charge_m, inhib_charge_p, inhib_charge_m
they contained the charge integrated up to this scaler event. so if one
wants to know the charge between the ith and jth scaler events, only need
to subtract the correspondent matrix in the two events.
in fact, total charge for the entire run is done by subtracting the charge
matrix in the first and last scaler events that IS ASSOCIATED TO any
physics events. by associated to a certain physics event, I mean this
scaler event has time stamp before the physics event while the next scaler
event has time stamp after that physics event.
>
> Tancredi Botto wrote:
>
> 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.
I agree. I think there is some misunderstanding on what dst is implemented
to do. It is a container of information. When trying to be as
comprehensive as possible, stability and efficiency in disk usage are
considered more important than convenience in Draw() command.
also agree on "i would not recommend TStrings for future analysis". simply
inefficient. It is very useful in prototyping cuts and so on but each
Draw() is a full loop over the entire Ntuple/Tree/Chain.
>
> >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST