Re: [BLAST_ANAWARE] Blast Analysis

From: Chi Zhang (zhangchi@mit.edu)
Date: Wed Jul 21 2004 - 21:32:09 EDT


Hi Taylan and all.

I agree on the issue Taylan raised about the status of BlastLib
software. After Tim and Tong left, a major part of BlastLib project has
been students working without guidance. In times, I do feel the
frunstration of lacking a person with more experience and authority
coordinating the effort in software developement.

Ofcourse I feel that a total rewrite of the software is not realistic.
The current BlastLib is the result of two rewrite, and I, probably all
students participated in the rewrite and developement are very exhausted
and really have a very hard time to vision another rewrite. I would also
like to say that Chris and I who do a lot of maintainance and develope on
BlastLib has tried our best to ensure the structure integrity of the
software package. Admittedly, facing the hostile nature of the design of
our detector, we some times do sacrafice cleaness for a quick fix, but
our intension has always been to avoid such conduct. However, it is my
second major software project(the first one being DGen).

I would like to express my opinion about the last few analysis
meetings. I feel the atmosphere in analysis meeting has degraded to
destructive and, in more than one occasions, offensive. If "Nessecity" and
"Significance" of people's work continue to be doubted at this meeting, it
would be very hard to attend in future.

I also agree with Taylan. that there are projects that take more than a
week, sometimes more than a week just to prototype or design. This is
not any less true in software engineering side either. This is made
especially the case when all of us have multiple projects.

Unfortunately the analysis meeting has always been rather results driven
such that engineering aspects are only touched upon extremely
superficially. I have to say, in the past, the benefit BlastLib software
developement received from the software/analysis meeting, may it be the
earlier conference room version, later counting bay version and the
current conference room version again, has been somewhat limitted, and is
not proportional to the length of these meetings.

Chi

On Wed, 21 Jul 2004, Taylan Akdogan wrote:

> Greetings to all,
>
> During the last analysis meeting I was asked to tell my opinion
> about what should be done for the tracking/calibration, and my
> contribution.
>
> In addition to this I'd like to state my overall impression about
> the blast analysis software, first:
>
> Blast analysis software needs a master coder-organizer-bitkeeper.
> PERIOD! This person should know every "key" details of the
> software system, and should be the only "authority" who checks in
> the "approved/reviewed code" into the repository, thus should be
> aware of every changes. Individual sub-groups can be the "expert"
> on parts of the system (like Chris for newton fit, Chi for DST,
> etc...), but the master should understand the general structure
> of the overall software system, and if/when the needs arise, s/he
> should be able to debug the code alone, and be able to find the
> faulty part and should work with the expert of that part
> together.
>
> As of today, there is no such person! It has been this way,
> correct me if I'm wrong, since the project began (or people left
> the project soon after it began), which makes it even harder to
> maintain. (Note that, reading someone else's code is always
> harder than writing a new code. That's why we need a software
> master who knows (almost) everything, thus can guide the other
> developers) From what I observe, the current trend of the people
> when a bug arises is in a direction to save the "day". Temporary
> solutions are preferable, or has the priority, rightfully,
> because other options may take more time than desired: Example:
> like skipping the events that crashes the analysis, instead of
> being debugged throughly my the master- developer who knows
> everything. Who knows, maybe, the bug which doesn't crash the
> event is introducing some other errors which is significant.
>
> So, what I recommend is that there should be a person assigned
> specifically for blast analysis, who has the above ability and
> experience. Then, there are two options: 1) S/he chooses to
> salvage the code and review all parts, and re-implement only the
> parts that is absolutely needed to be re-written, meanwhile, s/he
> makes the code more suitable for collaborative environment,
> instead of being a scrip-tic for a beginner (like chasing an
> obvious function that is defined in one of the header file of a
> class as an operator should be changed) 2) S/he starts from
> scratch, and salvage the parts of the code by adapting it to the
> new system. In either case s/he should review every new changes
> before applying it to the code. Although, option 2 is the best
> solution in the long term, I'm sure option 1 will be preferable
> for the sake of graduate theses. OR, instead of cleaning, and
> maintaining the code by a single hand, we continue to work on
> this as it is now; people make pretty good contributions and we
> apply them to the whole library, and it "mostly" works, which is
> certainly an option at this point!
>
> --- o ---
>
> As for the WC calibration; my contribution has never been
> intended to change the existing code "immediately", as it was
> re-thinkering of this task from scratch after seeing some
> not-so-appreciated results, which cannot/should not be rushed
> into the code; I experienced the giving away of "experimental"
> codes, later seeing them as being used for production. Think the
> version-0,1,2 of Compton codes, all of which were a side product
> of a graduate student who was spending a day or two at bates per
> month, aside from his thesis... (more examples are available some
> of which are still in use) I think the biggest contribution of
> the initial phase of that study is that we get better results
> (smaller segment errors) with my implementation as opposed to the
> current code both of which uses the same basic approach, pointing
> a bug or in efficiency in the old code. I agree at one point
> though; I should split the code into two, one is specifically for
> the calibration, the other one is for the tracking + calibration
> (as it is, now), so interested parties can continue on
> calibration. Although, I believe, the tracking, and calibration
> effort should go in parallel for the implementation I'm using, I
> must consider the possibility of being proven wrong, which would
> be good off course.
>
> --- o ---
>
> In addition to this, I was (sort of questioned which sounded
> slightly inappropriate, if I may say so) asked my priority list.
> I tried to give a summary. And, I think what I listed was not the
> complete picture, as I'm at a level of forgetting the items in a
> crowded list. All of them are interesting to me, and I'm happy to
> work on them, but it should also be noted that it is not a small
> list, and probably I wrongly volunteered to some of them. I intend
> not to add more items into those lists until it becomes a little
> cleaner during my stay at Bates.
>
> I'd like to give the latest (mostly) complete lists to those who
> must know. And, it should be noted that the items in these lists
> are interchanging depending on the progress and events. And, off
> course, I didn't included the "completed" items.
>
>
>
> High priority list (actively working on)
> ----------------------------------------
>
> 1) NPB: (this is here, because of some semi-hard deadlines)
> a) Finalize the np-bremsstrahlung analysis to get the
> publication quality results/plots.
> b) Contribute to the paper.
>
> 2) ND-Breakup: (this is in this list, as the trip to LANSCE approaches)
> a) Create the Monte Carlo simulation of the proposed
> nd-breakup experiment in Los Alamos (note that I'm a
> single person working on this project.)
> b) Construct the low level DAQ software (frontend) of the new
> breakup experiment for the new DAQ hardware. (I'll be in
> Los Alamos mainly to realize this part, between Aug 9-21!).
> c) Design and implement (and/or resurrect and improve an
> existing code) online analysis for monitoring and calibration
> of drift chambers, such that it is good enough to do the
> -necessary- calibration during the data taking period.
>
> 3) BLAST/COMPTON ANALYSIS: (this is the obvious)
> (This is the blast related project, I started to work on
> since I became a postdoc, and, now, we started to get the
> fruits out of this project. I think, it wouldn't be fair to
> stay in the background at this point, where I created a code
> base comparable to the BlastLib in size, including the
> DAQ software (as opposed to CODA) which works sufficiently)
>
> a) Work on/contribute to the Compton MC, and measurement systematics.
> b) Work on the Compton NIM paper (this is not as urgent, and
> has a well defined relax schedule, but working this in
> parallel to the analysis saves some time in the long run)
> c) Supervise a UROP student for the Compton result-database
> (this may sound an anti-job, but I assure you it is not!)
>
> 4) BLAST/ANALYSIS: (this is the important one)
> a) Blast Wire Chamber construction (call it tracking or calibration)
>
>
>
> Low priority list (either bothering me everyday or not requiring much time)
> ---------------------------------------------------------------------------
>
> 1) Contribute to the pion production (in NP) calculations/theory
> (eventually, it will be for my thesis paper)
>
> 2) Construct a spare DAQ for Compton and debug the memory problem of
> the ADC board we are using.
>
> 3) Blast Monte Carlo issues (this is the item I'm ashame of, I
> "volunteered", and I couldn't raise this item to the above
> list.)
>
> 4) Other bits and pieces of daily Blast issues as the need arises:
> Have an eye on the HV-epics system, write small scripts that do
> this and that to ease the life of the shift taker, etc.
>
> 5) Maintain the Compton software: This is always an ongoing
> process. However, it does not take much time, as I know every
> small detail of this software system.
>
> 6) Blast shifts: I tried to complete my responsibility on this
> as soon as possible, thus I'll be shift-free after a few more
> shifts.
>
>
>
> Taylan
>
>
> ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
> 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-402b
> ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
>
>



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