Re: [BLAST_ANAWARE] BlastLib2 version 3.0

From: Chris Crawford (chris2@lns.mit.edu)
Date: Tue Dec 16 2003 - 05:33:28 EST


i agree with chi!
--chris

zhangchi wrote:
>
> 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 ?

we could do this easy enough, or compare scalar charge w/epics charge,
since the luminosity is subject to change.

>
> ????? 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!)

unless the electron changes mass,spin,etc, the tof cuts only really
depend on the timing calibration, which is read from a configuration
file. even so, think of chi's ep_filter.h as a configuration file.

>
> I merged changes made onto blast account 2.96 branch to the new version,
> as instructed.
>
> >
> > *LET US NOT COMPILE IT RIGHT AWAY* !!

it's already compiled (in cvs_v3.0 ) we should really rename the
current cvs_v3 to cvs_v2.96, which is really what it is.

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

no so independent... in fact, it uses TBLDetRecon, the same
reconstruction class used in the new lrn.

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

the point is to have a quicker reconstruction, at no extra expense

> > 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....)

the filters are MORE time consuming if run separately
. this was initially yourr idea/request to run the filters together
with lrn, and i think it was a good one.

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