Re: [BLAST_ANAWARE] BlastLib2 version 3.0

From: zhangchi (zhangchi@general.lns.mit.edu)
Date: Mon Dec 15 2003 - 21:57:07 EST


On Mon, 15 Dec 2003, Tancredi Botto wrote:

> > >lrn produces lr, flr, dst and charge file. no need for the cycle of lrn,
> > >flrn, charge.C anymore. TB's ep_filter.h is included into the lib, his
> > >change on lrn/raw for spin flipper are merged in. charge file format is a
> > >little different. but for H2, only difference is in fill by fill charge, i
> > >write scaler and inhib charge for fills too. if it becomes a problem, I ll
> > >make they identical.
>
> what does it mean? the inhibited charge is measured with a scaler already.
> We should be migrating to a fill-by-fill charge anyways so that we can
> more easily cut on fill numbers...
It means I "accidentally" put both gated and ungated charge fill by fill
into the file. Well, you can't expect someone with 38C fever to write all
correct codes, can you.
no big deal, I removed the lines to output ungated fill by fill charge so
the two files are exactly the same.

init.C does not read anything below that line so IT WAS backward
compatible. and even so now.

>
> we should rather add a check that #-of-coda events is consistent with
> #-of-scaler(charge) events. Think of the ROC crashes or ET crashes. IT
> would be annoying to go back. What do you think ?

????? don't know what you mean

>
> Also, while at it, the raw tof-cuts should "read" B-field and choose cuts
> such as *_out(bending) vs *_in(bending).

code can recored out/in(bending), but only in the sense to record the
"-bm" value it is envoked with. if one made a mistake, it will be recorded
wrongly. it is not epics nor scaler but human input.

> I think we can have less stuff hardcoded.. but all the features seem there
> (including spin flip!)

I merged changes made onto blast account 2.96 branch to the new version,
as instructed.

>
> *LET US NOT COMPILE IT RIGHT AWAY* !!

at expense of loosing the 50% more recon'ed events, 60MeV vs. 90MeV
momentum resolution, 30+triggers/second vs. 20triggers/second speed?

>
> I'd want to wait at least until the spin flipper stuff is debugged and we
> can run head by head comparisons (or have you already ? let's see). In

let me REPORT what I did last few weeks again. first, wait for new
calibration, hoping it would improve tracking. did not see any new calib,
running out of time, start to tune the performance without new calib
anyway. 4 weeks, hundred of times want to smash the computer, I have a
library out performs 2.96. I crunched a couple of runs and the head
version is simply better. I have lr/flr/dst of quite a few runs in:
spud:~zhangchi/s4/blast/build_/BlastLib2/
check out the ntuples there and compare with the ones in blast:$ANALDIR.
also see the "numbers" I quoted above.

> addition, I do not see the need to integrate in charge.C, that is the only

I do not see the need to run the same commands through CPUs twice. since
most operations in charge.C are done in normal crunching anyway, I do not
see why one shouldn't do it in one pass. especially when we have all 16
spud CPUs busy all the time.

> tool that can give a feel for the experiment independently from
> reconstruction.... Particularly since we are going to lrn in a script, so
> that it was only a question of adding one line (root -l -b -q charge.C) to
> that script. charge.C was relatively fast, it's format was still in
> development, waiting for beam spin flip. Until tomorrow we do not

Fine, instead of develope charge.C, develope lrn.cc:MakeChargeFile(). or,
run charge.C afterward to overwrite the output of lrn.
 
charge is DST is recorded as 7*7 matrices by the way. with target
spin states occupying the right bottum 6*6 sub-matix, and element (0,0)
as the sum of charge in all states. right now (H2 state 1), charge will
appear in element (1,1), for D2 2-5 state injection, say, charge will
appear in element (2,5). there are two such matrices for raw scaler
charges and two for inhibited. one for beam helicity + and one for -. As
long as the atomic system is spin 3/2 or less, we would not need more
than 6 states. fortunately, we don't use any 3-state injection mode, do
we?

This idea is first discussed by Aaron and Vitaliy, I picked it up and
coded into the library. I put a littel twiest on it so the element index
is identical to the state numbers (1-6) and used (0,0) as a sort of check
sum.

I think this shall become the standard for charge, so for deuterium,
Q tensor+ = Q(1,6)+Q(3,4)+Q(3,6)
Q tensor- = Q(2,5)
Q vector+ = Q(1,6)
Q vector- = Q(3,4)
regardless of what mode we are running in. I left out two possibilities
with low "figure of merrit". please refer to lrn.cc::MakeChargeFile() for
detail. it shows how to retrive these matrices from dst and how to use
them. this way, there is no ambiguity, one can run "rm -fr charge_t20.C"
now. we either write something in init.C to open dst and grab and sum the
charge matrices, or write the full matrix into ascii files. copying
charge.C format to D2 was proven a hassel.

> have the right variable built in our spin/helicity-bits "server" and how
> that is done has to integrate with the rest of the experiment..... (scaler
> and electronics will "force" us to use an additional target bit, such as

I built N2 and He into the lib, but I am not sure that is not a joke.

>
> If things are bundled together in the new lrn.cc we need at least to opt
> out of 6hrs of recon cpu-time in order to check luminosities..... but even

that is not true any more. Thanks to Chris who found this autosave feature
in root. now after 5k triggers, lr, flr, dst will be all flushed to disk.
one can start to analyze lr/flr/dst after the first line of dots are
printed on screen. read behind your "-t" signature.

> then i still don't see the point ! Which is our problem: we want to have
> an answer before the data has been crunched.....
>
> I would argue against integration of the filters (that are more time
> consuming since we can have many of them....)

As for those timing cuts. Chris convinced me, once we have the timing
straightened out, we should have a stable timing cuts. only multiplicity
is for various Blast Fields. pad 0 in coinc with pad 14, proton has to
arrive, say 20ns, later that the electron.

If somehow, a peak missed a cut, that means timing is messed up, and we
should debug timing instead of change cuts.

that is why I finally decide to put charge.C feature into library last
Friday.

as for ed elastic, I ll tell you the rate and asym, you don't have to
worry about it.

Anyway, I was asked about the new version quite a few times lately. Now I
delivered it, and I belive it performs better than the current version in
use.

>
> -t
>
> > >autosave saves all ntuples every 50k events(one line of dots), after
> > >first line of dots, one cas start to look at the results. autosave deletes
> > >the last key. however, Write() does not delete last key so in the end each
> > >tree has two keys. but that don't matter anyway.
> > >
> > >to open dst file one must load libBlast.so first. curiouse people can use



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