[BLAST_ANAWARE] BlastLib policy

From: Tancredi Botto (tancredi@mitlns.mit.edu)
Date: Tue Nov 26 2002 - 15:17:28 EST


Chi,
we quickly went around the problem with DetRecon by using previous
bits of code commented out in ntuple.C (still, my comment about
the cut above pedestal to identify a hit stands in DetRecon. We should
only use tdc information in determining the hits. The adc is too soft).

a) Anybody can modify, add NEW classes to the library

b) Nobody can modify current macros. PERIOD. But you can negotiate w/ me
  (basically, I'll let you do the work but I'll make sure you test it...)

c) Nobody should check in new library versions if they are not tested
   Unfortunately it happens but is now a lesser problem

We can still use the devel directory and have a mechanism by which
we absolutely know which library to link to in ~/lib  I don't mind having
10 libraries but I want everybody to be quickly able to know which one
they should use.

I've neglected this. But the above points have been re-iterated many
times !!!! I think we need a changelog file in ~/lib. Which I'll do next

-- 
________________________________________________________________________________
Tancredi Botto,  		phone: +1-617-253-9204  mobile: +1-978-490-4124
research scientist		MIT/Bates, 21 Manning Av    Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Tue, 26 Nov 2002, Chi Zhang wrote:

> > Hi, I guess I would be under fired again and have a lot of sorry to say. > > I am having trouble composing emails on Athena, so pleas forward this messge to blast talk or any group you deem appropriate. > > I checked in v2_6 Sunday morning which included quite a bit changes. However, I did not test it with ntuple.C since I took for granted that no interfaces ntuple.C calls were changed. Guess made a very bad assumption. > > Here is a summary of changes on blastlib I made during my two weekend morning shifts: > > Nov 20, v2_4 was checked in. Chris did it from office. Including the changes I made on 17-19th to include neutron counters into TBLDetRecon. I tested with a run on 19th in the evening, I see good neutron counter tdc/adc spectra. So I think this one should be fine. Ntuple.C is changed accordingly ofcourse. > > Nov 23, v2_5. minor changes. Nothing should be different from v2_4. I added a few constant qualifier. > > Nov 24, v2_6 and v2_6_1. Huge surgical operations. Codes are moved arround as Tim and Chris suggested. I wanted to finish this a long time ago. But probably some technical problem occured. I also added new functions to do PID. I did not test it with ntuple.C as I took for granted, nothing interfacing to the script was changed. Now I believe it was a very bad assumption. > > So, I guess we need to go back to libBlast.so.2.5 or 2.4, since no one complained during Wednesday and Sunday, I think this version is generally fine. If not v2_3 but revert ntuple.C also. The revert is as simple as making a simbolic link in lib/spud > > I am very sorry for the disasters I created. Since for the last week and the next couple of weeks, I will be doing developments at home, please call my home phone if you suspect I was the conspirator of some software disaster. > > I do not understand why both nuple.C and Pete's calibration are complaining. Seems something is very wrong with DetRecon. But it is also alos that I did not check compatibilty of new TBLDetRecon and TBLScRecon. Since I did not have enough time and it was 4:00am in the morning. > > Unfortunately, the PID part of BlastLib2 will be still under heavy construction since there was almost no codes toward this direction before October. There are two kind of changes that I v been making. One kind to make online scripts a bit shorter and easier to write, the other, I take as one of my major projects, to construct particle ID for blast. Unfortunately, the first kind of changes should be installed into lib/spud instantly so I v been ci and installing libraries much much more frequently than any one. Yet it is hard to seperate the second kind of changes from the first. > > I will look at v2_6. To see what the heck was going on. > > Pete: the subtraction of TDCoffsets and pedestals are done in calib_tof_in_channel, as long as the offsets are written into blast.sc_cal. I propose to add a new column to blast.sc_cal for the speed of light in the scientillators. blastmc assumes 0.02cm/ps, which is certainly not he case in reality. So for MonteCarlo study, we may need to keep a seperate blast.sc_cal_mc which lists 0 for all TDC/ADC offsects, 0.02 for all speed of light, 50 for all TDC/ADC scales. Otherwise, the speed of light will have to be hard coded into TBLDetRecon and the codes need to be recompiled any time one wants to change from MC data to real data. While a real blast.sc_cal or mySQL for real data. The same applies to electronics.map. > > ALso Pete: could you give a description of the sympton? does it crash when you instantiate TBLScRecon? I kicked out TBLGeometry from TBLDetRecon as Tim wanted, I added a instantiation of TBLGeometry in TBLScRecon. but it was not fully tested. I am not sure I made all the changed required since my brain started to shut down at the moment in the morning. > > Chi Zhang > > > > > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now



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