I agree with Steve that it has become urgent for us to have an
agreed-upon comissioning plan with enough detail so we all can
contribute in a coherent way. Similarly, we need to understand the DAQ
software structure in order to know what to write and how to write the
detector-checking code.
Mac has made a good general start, and I appreciate the update
he gave of the current work this week. We need names of people listed
next to the various items, and dates (approximate at least) as targets
for when different items need to be ready. Mac writes that comissioning
shifts have started. Is there a shift list? Who is doing what work?
When is "my" shift? When are the peak times when we need more manpower
at the lab? Without information of this kind, I predict that we will
still get the project done, but in a less efficent and slower way,
hopefully without any boo-boos, and with the labor not equally
distributed among the participants.
Steve wrote about the division between MONITOR software and
RECSIS/offline software. As I understand it today, there are two
independent suites of software under development: online software for
checking 'simple' things about the chambers (MONITOR), and offline
software to do the arbitrarily complicated track reconstruction and
track correlation software (RECSIS). As Steve says, it is not clear how
far we should develop the 'simple' online code, since the time will come
almost immediately when we will want to do increasingly complicated
checks on the equipment. Good example are: what if we want to look at
hit patterns for events with p > 1 GeV/c? or hits for events with
correlated hits in the TOF counters. My point is that we should invest
as little time and effort as possible in the 'simple' stuff that will be
thrown away anyway. Any rudimentary checks MONITOR can do, RECSIS can
do as well. I was told that any given MONITOR will only process
information from one detector. If I want information about the TOF
detectors or about the results of tracking, why should I have to unpack
and analyze that information on my own? I should be able to call
standardized unpacking and analysis modules for other detectors. But
this is the functionality within RECSIS, is it not? Another way to say
it might be this: to a certain degree the detector IS the software.
Without the software the spectrometer is a useless pile of metal and
plastic. Therefore, why build part of the detector twice? As long as
you are writing software for the device, why not make it part of the
permanent structure from the beginning? The offline software should BE
the online software, perhaps with some of the bells and whistles turned
off. Clearly, I have a certain view of the distinction between online
and offline software. I freely admit I have not studied the software
some of you have been working on 'til now, and may therefore be all wet
on this. If so, could you fill in the discussion group on what your
views are?
Regards, Reinhard