I want to start to respond to Mac's outline of procedures. I will focus
on software because I see the biggest needs there. First, some people
have complained about the tone of my note 2 days ago. I have no desire
to offend anyone, but am fairly concerned about the need for a MORE
DETAILED plan and fairly frustrated about my inability to get to TJNAF
this semester. I apologize to all who I offended. I also recognize that
I have done a lot of detector commissioning and have somewhat strong
opinions about the process because I've seen (and made) many mistakes
through lack of careful planning. A major problem in early days is
that not much software or hardware works and you have to design procedures
that work in an environment of fuzzy knowledge. I have had good
discussions with Jim Mueller, Reinhard Schumacher, and Dave Tedeschi the
last few days and will report some of the thoughts that developed. (I
wanted this email discussion group to play a similar role, but I see it's
much harder. We need a group mtg at CEBAF!!)
I wonder about processes like plataueing the chambers where we need
fast information gathering. A key need is a minimal set of software
and a way to identify events that should have made a track in the
chamber. With cosmics, this identification is fairly easy because
multiplicities are very low and background is negligible (once the
electronics is set up correctly). With the beam, we will probably
have a loose trigger and lots of background. I believe we need some
way to siphon off events containing tracks of high momentum (straight
lines, easy to do simple tracking). I don't know enough about Hall B
DAQ to have the answer, but let's speculate. Hardware is likely hard
because you need TOF or calibrated shower counter info. Unfortunately,
there's no level 2 trigger. In software, we could have a simple search
for a *cluster* of hits in a sector in a MONITOR program or use
hit based tracking in RECSIS or use scintillator info in RECSIS.
This brings up the issue I tried to raise in the previous note.
Do we do this online or offline, with the MONITOR process or
RECSIS? We have argued a lot about that here. I believe we want
to do it in MONITOR because we control everything in it and I
think we can do very simple tracking to identify the events we
need. We can check things for consistency online and do a more
careful analysis offline. RS disagrees, says we should do everthing
in RECSIS. JM points out the need (not yet implemented) in DAQ to
write a secondary tape of a subset of events based on cuts.
THat reminds me, the MONITOR process I have seen looks like a
great start, but needs much more if it is to be the workhorse of
our commissioning efforts. We will have to have some way
to identify the class of events we want for our chamber tests. I
think toward high momentum again, maybe there is an easier way?
Use Cerenkov to identify electrons? (which Cerenkov detectors?)
I also worry about a need to identify problem wires in a HUGE histogram
and the need to correlate wires in different layers or in different
sectors. What wire is that one that is hot? Who is nearby? (We
have done a lot of that already in commissioning, is it good enough?)
I also desire more flexible programming than PAW in fortran
because we will be changing that code constantly for the 1st few months,
but we probably don't have time or manpower to do that. CLAS event
display will be a great tool, but do we have capability of seeing
ONLY events that pass some cuts?
I should stop here because I make many assumptions in my analysis
that might be argued.
regards,
Steve