=== Adam Lyon's comments ===
         on CLEO frameworks and D0 Run I frameworks
               (Nov. 19, 1997)



So Cleo has two main program frameworks, DRIVER and CLEVER. DRIVER is mainly 
meant for analysis programs and reads ROAR files, which are the cleo 
equivalent to D0's microdsts (cleo has two file formats - ROAR and FZX - the 
latter containing the full data like an STA). The way it works is DRIVER 
expects you to put code in certain routines, called anal1, anal2, ... anal10, 
each of which gets called at certain times. For example, anal1 goes at the 
start of a job, anal2 is executed at the beginning of a new run, anal3 goes 
for each event [so most analysis code goes in anal3]), you get the idea. Then 
you link DRIVER and run the executable. The DRIVER program is much more 
complicated than D0USER - you can give DRIVER run & event lists so it will 
only process events in the list, you can give it some rudimentary cuts to 
apply, it will automatically make some histograms, calculate luminosity 
[though most people don't trust that feature and do it themselves]. But there 
is no way to make "packages" like you had with D0User. You could fake it by 
just calling the proper routines in anal2 and anal3, but it's not automatic 
like D0user. In fact I've been bitten by running "packages" people have 
written and forgetting to add the begin of run call for the package that 
needed to go into anal2.

I actually really liked the D0 program builder, especially in that it would 
automatically write a link script for you. At CLEO, there are standard 
makefiles for DRIVER and CLEVER which link in every CLEO library they can 
think of - so linking takes forever. And I've had problems with unresolved 
symbols which meant I had to go into the Makefile and figure out what library 
was missing or reorder the librarys in the list. Arrrgh!!! Quite painful. 

The CLEVER framework is more like D0USER in that it does have the notion of 
separate packages, but it's mainly meant for running reconstruction (it can 
read the full FZX data files). Instead of using something like the D0 program 
builder to put things together, you have to add code to a KUMAC script (yes, 
that's from paw) to tell it to run your code. There's another routine that you 
have to add code to (and I've forgotten to which causes all kinds of strange 
crashes). You then link CLEVER with your code. When you run CLEVER, it 
actually starts up a KUMAC session where you tell it what to do. Very 
complicated.

So the upshot is that though program builder might not be the easiest thing to 
learn, once you learned it, it was fairly easy to make things work. Here, it's 
not so simple.


-- Adam