Introduction

SNOMAN is not perfect (although the authors like to think it comes close!); invariably the user will want to do more and then the only option is to write code and link it in. In this section we will describe how to do that, but before we start, it is necessary to briefly review the organisation of the code. The code is divided into Software Units (SUs). Most SUs have initialisation and termination routines and one or more execution routines. The SUs form layers, higher level ones depending on lower level ones. There are two types:-

Processors

These are ready to run units that perform some operation on the data structure when called. For example, a fitter is a processor.

Support Systems

These provide a service to processors or other SUs. For example, the detector geometry is a support system.

SNOMAN has been deliberately designed in this modular way to allow it to be as flexible as possible. A system, called SU CONTROL, that is built into the framework of SNOMAN, knows about the SU interdependencies and ensures that only those SUs that are needed for the current task, are brought into play and that they are initialised in the correct order. A user could deal directly with the SNOlib library from which SNOMAN is built, combining SUs and private code in any suitable way. However, this is a risky strategy to follow unless the dependencies of the SUs are fully understood, both in the way that the higher level ones rely on the lower level ones and the way the processors couple through the data structure. So a better approach is to exploit a set of user routines that have been built into SNOMAN. These allow the user to build programs that have as much or as little of the functionality of SNOMAN as is required. They allow the casual user to concentrate on the task in hand without getting bogged down in the internal workings of SNOMAN.

There are three types of user routine:-

SU User: *_USER.FOR

These are plug-ins that extended the capability of a particular SU, usually a processor. For example there is a Monte Carlo user that can be changed to allow positions to be generated according to a user's algorithm.

Standard User Interface: USER_*.FOR

This is much more powerful and in effect allows a user to modify any processor. It offers a smooth migration path starting with very modest program changes, but permitting these to develop into extensive ones.

The USR Processor: USR_*.FOR

This is less powerful than the Standard User Interface but represents a beter way to intoduce genuinely new code as opposed to modifying existing SUs. It can be used as the basis for any sequential event processing analysis code.

It is slightly easier to deal with SU Users, so these will be dealt with first.