SCRI/FSU (904)644-0180[224-1837], 14-MAY-1996


Jim,

I'm sorry I will not be able to attend the review on May 22. This seems like a
very useful exercise, so I'll give my view of things with the hope of further
improving the system for run II.

My point of view is that of a "physics users of the system and simulations" and
"physics group" representative.

First, without knowing all the details, the system seemed well designed and
implemented with the requisite generality and flexibility to accommodate  the
variety of running conditions we experienced. It was not, however, an easy
system to use or learn. My recollection is  that it was quite frustrating
because of jargon like "tool" and "parse list". The algorithms we would have
implemented were trivial compared to the learning  curve. Indeed it seemed like
learning a new language. An "idiots guide" would have been useful. By the time
we had found a guru willing to lead us through( usually an MSU grad student) we
were so far into the run that we did not want to change anything for fear of
having twice as much work offline. It would have saved alot of disk space if we
could have linked the simulation to the front end of reco, rather than dealing
with .STA's times two. 

After the end of run Ia we had difficulty determining what value was used
for the isolation cut in the special runs. The data looked funny and Sal
found it very difficult to find the number that was used and it turned out to
not be the one requested.

From a physics point of view, the L2 triggers were slow to turn-on mainly
because of showers hitting L1 and readout boundaries.  To avoid using turn-on
curves to correct for efficiency in steeply rising regions, we threw away about
half of the recorded triggers by using an offline threshold ~1.5-2 times
higher than the L2 threshold. In retrospect, a fiducial cut tool might have
saved a larger fraction of useful events. Also, just reading out more of the
calorimeter might have eventually been more efficient.

A few finite problems:

First the inability to convert the code from VAX to AXP caused us to keep a
bunch of old  machines alive to this day.

Second, There is a bug in the simulation which caused saturation at high rapidity and
high ET. The problem was that no one believed us when we showed them turn on
curves that never turned on fully. It was suggested that run the debugger on
the L1/L2 sim and locate the problem. Fortunately, Amber was willing to do this,
or the problem might still exist.

Both could have been sorted out with more manpower for the long haul, or found
much sooner if the system were easier to learn.


For the future some aphorisms:

"KISS - Keep It Simple, Stupid"

Make simplicity a design goal. This does not mean writing an elaborate "user
interface" that  hides what the program is doing. Avoid the layers of code that
do nothing i.e., do really need a function to fetch a "bank" pointer? This will
make it easier to maintain the code and train experts.

"If it aint broke dont fix it."

I worry that  a 'top down' redesign of the system will introduce an unfamiliar
system with a whole new set of bugs, that will take years to find, not to
mention the man/years for code development that could be spent in testing the
hell out of it before run II.

"My cat is object oriented."

Conversion of the code from Fortran to c++ should not be used as an excuse to
redesign the whole system. Most of the conversion can be done with existing
preprocessor's and/or manpower that can easily be allocated to such a well
defined task. The problems we had in run I were not structural, but trivial
coding  errors that were hard to find.

I hope this helps.

SLL

                                                 MSU 517-355-3328, 16-MAY-1996

    Steve,

    Was the problem with the documentation that it was incomprehensible, or
out of date?  We had made what we thought was the "idiot's guide", l2sim.doc,
but it sounds like that missed badly somehow.  Any chance you could go through
it with one of us to point out what needs to be done better?


                                   Jim
    

Jim,

I can't find my hard and marked-up copy of L2sim.doc; however, 
I just looked on disk and found it to be a model of clarity and thoroughness.

Fortunately, I'm not the idiot I was 2 years ago, in a hurry to 
get a TRGR bank on my MC data.

One suggestion to improve the documentation, in general, is give it to a
novice and wait for questions. I find my own documentation,  
even though complete, may not always be in the best order.

It has been suggested that I get involved with the upgrade L2/3 in some 
capacity, lets see how that works out before I volunteer.

SLL