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