Hi,
the charge script will run as a compiled script soon (it works, it is
a bit of a time saver, and it makes it more stable). There where more
run-dependent patches added in these past few days. Can't promise won't
happen in the future. I really would like to emphasize that the spin bits
are important !! It's not just a problem of interlocks but also of
procedures that we will all need to strictly follow when changing
targets (empty, unpol,abs).
I think running with spin flipper seemed ok, but please note the
problem with "helflip" mentioned in elog (will not be a problem after
refiltering, I hope I did not do anything stupid with cuts.C). I mounted
/scratch/dblast07 on every dblast machine... not sure what happened.
If dst.cc is in sync with all of the above, I'd like to ask chi
to just
cd cvs_v3.0
make install
and v3 all the way...
> however, the lrn in library will process epics/scaler and integrate the
> charge. in order to make analysis possible before the entire run is
> crunched, I will add a small tree with charge(total and by fill) info to
> lr and flr root file
I think this is a needed improvement. One problem we will face is that
everytime we select (or discard) data based on - e.g. - a range of beam
currents, bad or "long" fills, bad target (vacuum, tune) we have to
recalculate the charge and the normalization.
Right now this is done by hand. But in the long run this is not good for a
DST. It is also not good when analyzing data over long period of times.
I propose that data should be selected using quality flag for beam,
target, compton, detector. The value of subsysA.quality may become 0,1,10
meaning "indifferent", "data is good", "data is excellent". The goal is
data I could select data according to the criteria
(abs.quality==10 && beam.quality == 10) (in this case I choose not to care
about compton and detector, or maybe a compton quality is not available).
I could also select "wch.quality>=100" meaning I want all data when all
the wch boxes are on and not noisy.
But if I would do this, I'd have to recalculate the charge, which may not
be what the next guy/gal wants for his/her analysis. So having more than
one charge branch, or organize the charge in such a dynamical "matrix" is
much more ideal.
I definitely had other ideas of what trees and branches were before jumping
in on root, but I think this can still be done.
> I hope this presents a solution to meet the need for quick diagnostics
> for number of elastic events from TOF(i.e. charge.C) and the need for
> before-crunch-is-done analysis.
>
> Chi
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST