Re: [BLAST_SHIFTS] SFT RF broken

From: Chi Zhang (zhangchi@MIT.EDU)
Date: Fri Apr 15 2005 - 23:36:42 EDT


OK, Genya,

I just checked into CVS a new source qlrn.cc which is a stripped down
lrn.cc. As you wanted, it processes trigger 1 events only. it would take
about 2 hours to process a 1M event run so after that you can use it for
target diagnose. the program will write a "flrpm" ntuple into
fflr-#####.root file.

lrn.cc itself has become so complicated after many required features have
been put in that modifying it to add another running mode would take much
longer.

I compiled qlrn in ~blast/cvs_v3.0/BlastLib2. someone need to put it into
blast bin dir and modify autocruncher to run it. I would like to leave
autocruncher part to some one else as I am not farmiliar with it.

But my view is that this is a horrible way to get information on target
performance. To gather enough statistics, the turn over is not much better
than two to three shifts anyway. Shouldn't there be EPICS monitors to
ensure the proper functioning of SFT?

again, Chris and I spent a lot of effort digging the AutoSave()
feature of ROOT so every 50k events crunched are flushed to ntuple files
with proper charge. This meanse even with current software setup, a lot of
events are available for asymmetry analysis EVEN BEFORE the runs are fully
crunched. The only down side is you see a lot of ROOT warnings. I am not
sure why one would want a stand alone "faster" version of lrn which
ultimately increases CPU demand by some 15%.

Anyway, you have the code you want.

Chi

On Fri, 15 Apr 2005, Genya wrote:

>
> Today, at about 3 PM I found that SFT doesn't have RF. We've lost it
> yesterday, somewhere between 8 AM
> and 4 PM. Somehow I missed the signs of the failure duting my morning
> check-up. But it does emphasize the importance
> of express crunching to be introduced - we would catch the problem
> immediately.
> Anyway, it appears that we can't fix the problem until Defa returns
> from Europe, which is, fortunately, tonight. It looks
> like that the main RF amplifier for 400 MHz is down, and I don't know if
> we have a spare. We'll run unpol deuterium
> until Defa comes in and sees if he can fix the problem.
> Genya
>
>
>



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