Software Architecture

There are two separate codes responsible for the geometry:-

GEO

The Detector Geometry. This is a general embedding geometry with full support for REGION, NEAR, NEXT and PICK. It is used for all regions of the detector except within the internal PMT structure. It is the architecture of this code that is described here.

PMT

The PMT Simulation. This is a hardwired geometry that deals with the internal structure of a PMT. It supports NEXT and PICK. The PMT code also includes photon transport which uses this hardwired geometry. For a discussion of its architecture see 12.7.

This structuring was done to allow the full optical response of a PMT to be as fast as possible whilst allowing a flexible geometry elsewhere. However for simplicity, the GEO code will call the PMT code to deal with PMT regions so the interface provided by GEO can be used for all regions.

The GEO software is organised into 4 tiers:-

Interface

These routines present a simple interface to the rest of SNOMAN. They pass control to routines dealing with specific elements of the detector. Routine names are: GE_* e.g. GE_NEXT.

Detector Element Routines (DER)

Each of these deals with one detector element. Routine names are: GED_*, GEDA_* and GEDX_*. The top level is the GED routine e.g. for the acrylic vessel it is GED_ACRV. This routine knows the relationship between this region and its neighbours and calls the appropriate GEDX routines. In the case of GED_ACRV it has to call GEDX for the external boundary of the vessel itself (GEDX_ACRV), and the GEDX's for the external boundaries of the D$_2$O , the chimney and the belly plates. The GEDX deal with a single external boundary. For example GEDX_ACRV deals with the external boundary of the acrylic vessel which is simply a sphere. The GEDA routines exist only where there is an array of elements e.g. belly plates. Their purpose is to provide optimised searching. For example the acrylic vessel has embedded within it a set of belly plates. In principle it could call GEDX_BLY_PLATE for each one but this would be very time consuming. Instead the concept of array of is introduced and the routine called is GEDA_BLY_PLATE which attempts to limits calls to GEDX_BLY_PLATE to those belly plates that are relevant to the current request.

Geometry Primitives

Each deals with a single (usually simple) geometric shape. Routine names are GEP_* e.g. GEP_SPHERE. This layer exists because some shapes e.g. sphere and cylinders are reused by a number of detector elements. So rather than have each detector element deal with its own geometry, each calls one or more GEP routines to build up shapes of arbitrary complexity by ORing and NOTing primitives together.

Boundary Manager

This takes output from the geometry primitives and combines them to calculate the detector element boundaries. Routine names are: GEB_* e.g. GEB_START_GEDX. This layer exists to simplify the writing of GEP and GEDX routines; which work in isolation. Each GEP deals strictly with one primitive shape and each GEDX deals strictly with one detector element external boundary. All calls to GEDX and GEP eventually result in calls to GEB whose job it is to take all this information and resolve it in the context of the current request.