NOT UPDATED

book95's code and flow structure

Overview

Book95 has (or was intended to have) a multi-layer structure.

The base are those that i call "steering" routines, in dumread.c: main, find1stini,readbaseini, help, read_1_file, read_n_files. These control the order in which data files are read, and the general program behaviour; in principle, they depend very little on the data format, assuming just the dumle naming convenctions and files made of a header plus blocks of data.

The dumle data readout routines are readheader, readblocks, readfirstheader, checkheader; they are helped by printsetup, printevset, printuinfo. The first one takes care of the real work; the second is used by readfirstheader and checkheader respectively for identification of the data format and for a check of its coherency along the various files that are read.

On top of this, there is d2n.c, that takes care of the reading of the ini files and of the transformation of data for use by the "user code". In this, it is helped by the routines in ini.c, that decode the data in the ini files and store them in the proper data structures, and lbook.c, that takes care of most of the interface to the CERNLIBs and in general of the data storage

The topmost level, that i usually call "user code", is book95.F. I call it like this because, given how much more effort required to me to write it in fortran instead of C, for the sake of making it more readable by others, i REALLY hope somebody, some "user", will get her/his hands dirty with it... :-)

Apart from jokes, book95.F receives the clean data for each event in the xdc array, calculates the "new" variables and stores them in the xcal array, and decides whether to store the event in the ntuple. Then there are a few other "support" routines, and empty places where a user might like to add something, like beginning and end of file and of ntuple.

Left out are still uti.c and profile.c that provide some low level machinery for, respectively, various use and ini file readout.

So, this was the idea: d2n receives data from a "file reader", does any necessary cleanup, and passes the data to some "user code"; and doesn't care at all about what they actually are.

Actually, being this a real world, it turns out that it does care; a bit, at least. Just what is necessary not to make things more complicated than they deserve to be.

Book95 complicated treatment of Drift Chambers actually required a large and complex set of constants that couldn't be easily be specified and managed like the other "user" constants in the ini file, so special code for geometry constants readout is found in ini.c; the per-block informations (scalers readout) are (eventually) printed in blockread (dumread.c); and a few other things.

Also, book95.F grew up to be quite complex, and not something anybody could wish to rewrite from scratch, so it's not really anymore just "user code". Anyway, i still think that it's something one could want to modify, and so i'll give quite some details about it - tought it's anyway quite full of comments.

Now it's time for the details:

d2n.c

lbook.c

ini.c

this is the place where to look for if you have doubts about the readout of constants. book95.F

profile.c