Hi,
I made some changes in lrn and TBLDst and added new files to the
BlastLib2 for a new auto-cruncher I was working on. It all worked
fine on top of v3_4_7 in my account.
I copied my changes into ~blast/cvs_v3.0/BlastLib2, and tried to
compile in that directory. I was planning to tag it as v3_4_8,
but everything went crazy (don't ask the details.)
Apparently, you were doing other changes in this directory,
probably at the same time, while I was pulling my hair :)
Could some one more familiar with CVS apply the changes on top
of Chi's changes. I put the modified files in
~blast/new_auto_crunch_changes directory.
This shouldn't effect any analysis part; it is pretty much a
standalone code for passing useful information to the
auto-cruncher.
Once I have something to work on for debuging the (new)
auto-cruncher part, I can add the qlrn to the crunch steps.
Taylan
On Fri, 15 Apr 2005, Chi Zhang wrote:
>
> 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
> >
> >
> >
>
-- ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--- Taylan Akdogan Massachusetts Institute of Technology akdogan@mit.edu Department of Physics Phn:+1-617-258-0801 Laboratory for Nuclear Science Fax:+1-617-258-5440 Room 26-559 ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST