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

From: zhangchi (zhangchi@general.lns.mit.edu)
Date: Sat Dec 20 2003 - 22:10:32 EST


On Sat, 20 Dec 2003, Tancredi Botto wrote:

>
> Hi,
Hi, glad we are moving toward agreements. I take your arguement about
having a quick quality check, but until Friday morning, you did not realy
say that. :)

> 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

I will put dcct calibrations and scaler slot numbers and so into an
ascii(of course it is the most correct way to put it into data base) so
library will parse and pick proper run-dependent calibration.

However, the situation in those few runs after 4044 is hard to deal with
when the target status bits was wrong to begin with. Person on shift will
have to look at the screen and check all channels are in proper state.

> If dst.cc is in sync with all of the above, I'd like to ask chi

I ll check elog and see what is the deal with the flipper. In the
meantime, I am trying to make some changes. right now the new lrn had to
be started after the run is end since it processes epics/scaler first in
an independent pass.

I want to change it so that one can start crunching right after the run is
started.

This will allow us to do longer runs, crunch when taking data(if we have
enough CPUs) and the features in new lrn will allow extensive
analysis(including asymmetry) in the mean time.

I updated init.C to work with dst too, Chris has made a dst.C and checked
into CVS. one thing left is to read the charge from the charge Tree in
lr/flr root files. this is must if one wish to do before-crunch-end
analysis, as one needs the charge associated to only the events crunched
which is recorded in the charge Tree, instead of the total charge which
is recorded in charge file.

this change would be a little non-trivial, and may take my the next few
days.

> Right now this is done by hand. But in the long run this is not good for a

in dst, I record integrated charge in every scaler event. a physics event
has a scaler event number through which the scaler event directly before
it in time is retrievible. This is done automatically when one uses
TBLDst::GetEntry(i). charge up to the ith physics event can be calculated
by charge in current scaler event less the charge in the scaler event
linked to the first physics event.

In principle, charge associated to any group of physics events can be
computed this way without opening raw data file and integrate again. but a
few lines of codes will have to be written by the user to pick out the
scaler events and do the appropriate subtractions and sums. for instance,
if one picked the 15th physics events up to the 30th, the charge for thise
15 events will be done like the following:

// opened a dst-####.root file and read into a TBLDst object called dst
dst.GetEntry(15);
float charge0 = dst.scaler->inhib_charge_p(1,1); // hel+,H2 single state 1
dst.getEntry(30);
float charge1 = dst.scaler->inhib_charge_p(1,1);
float charge = charge1-charge0;

it is probably possible to make a function in TBLDst or in global
scope that accepts a cut and loop through the entire file/chain and
compute the charge of all the events passing the cut. but it is a
bit tricky in that it has to handle the gaps between events caused by the
cut. I ll think about it.

> (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

any guy/gal dependent thing will have to be dealt with the guy/gal, we can
think of things to do to make the life of the guy/gal a bit easier. for
example the charge function I mentioned before.

> one charge branch, or organize the charge in such a dynamical "matrix" is
> much more ideal.
>



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