> 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.
agreed. Plan is to start jan 19 with d2. Hopefully this spin-bits
problems won't come up again. I think we are all set for the charge
for 2003 data.
> I want to change it so that one can start crunching right after the run is
> started.
But how do you know a run is good before it has ended ? I have no
objections however. And I'll provide a script for that. I think it'd be
more interesting how to use the most of the coda data file, which was
probably good before a run crash.
et_crash: should be no data anywhere, so should be easy
roc_disconnect: if charge scaler stays inhibited should be fine
but I have not poked into those runs. hv crash: ? other_crashes ? I also
don't know what to do.
> 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.
I can immagine. Maybe you keep the charge files and charge.C will just
update a database. Fine with me. There will be two programs to update but
hey, we love to work harder. But isn't the advantage of dst that all info
you need is in it, and you don't have to walk away with 4000 or so chg
files ? maybe one day I'll understand.....
more importantly, for sake of clarity: of course you can't select data
based on physics event numbers because we do not measure the charge
between any two physics events. We only measure the charge over one scaler
read/clear cycle (typically 1 sec) and you can't break it up in smaller
intervals than that.
step1 is to throw away fills, and play it safe. most of the work is done
there
step2 is to throw away scaler cycles (and the one before/after it) but
then of course you are synchronization dependent, and sure the roc's
have ntp running but... it maybe be a lot of overhead we don't want.
I'll be more than satisfied if we can do step1. I think we will never have
to do step2, if we have a problem is likely to last several seconds anyways
The cure there is take "good data" instead of taking "any data" and try to
patch it up later.
And I think that it'd be easier to cut on flags and indicators (instead of
(fill>23&&fill<50)||(fill=51)||(fill>53...) do beam.quality>1) ).
> > 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