1. INTRODUCTION

In any High Energy Physics experiment, detector simulation is of great importance, not only for the physics analysis, but also as a hard-ware and soft-ware development tool.

Traditionally, H.E.P. simulation programs are either pure physics simulations, or complete detailed detector simulations.In the first case, one generates the initial physics process according to a theory, eg. decays of the $Z^0$ according to the standard model. Since no information on the detector response is included, such programs cannot be used to design a real-life analysis procedure, other than very crudely. In the second case (which usually also includes the first,as a sub-program), as much detail as possible included of the detection process, eg. ionisation in gases, electronics response, interactions in the material of the detector, and data formatting according to the actual detector read-out system. As a consequence, such programs are very demanding in terms of computer resources, both CPU-cycles and data storage. In fact, the LEP experiments at CERN are typically producing simulated $Z^0$ decays at approximatively the same rate as they are recording real ones. While such complete simulations are absolutely essential for the physics analysis, their sheer weight make them hard to use for the individual physicist, and producing events in the amounts needed to be statistically significant must be centralized at large computer centers having the needed resources in terms of CPU-cycles, mass-storage capacity and, last, not least, man-power.

Hence, there is a need for soft-ware at an intermediate level of detail. Such a system should make it possible to produce significant amounts of simulated events at the home-institutes, or even on a PC at home. The events thus produced will of course not have the detail of the full detector simulation, but will be vastly much more realistic than the output of a bare physics simulation. The existence of such a program will make it much easier to test 'wild ideas', because it doesn't interfere with the work of colleagues to run such a test a short time on a single work-station on PC. This is in stark contrast with the case of using a large scale detector simulation, where days of CPU-time on a high-end system might be needed, GigaBytes of data might be written, and assistance of operators will be needed. In addition, with such a fast detector simulation program, theoretical physicists with no close contact with colleagues in an experiment can test the experimental implications of a theory without having to learn un- reasonably much about detector performance.

The Simulation a Grande Vitesse (SGV) is such a program. It is a detector simulation program, designed to yield a fast answer to the question of experimental visibility of a theoretically predicted process. It is accomplished by the implementing a simple description of the detector, giving low over-head for the initial setting-up of the program, and by a fast simulation code for the detector response, making it feasible to perform high-statistics simulation, even with limited resources. By applying SGV to the DELPHI detector at LEP, it has been shown that the time to simulate the detector is of the same order of magnitude as the time to generate the bare event. It is also shown that, despite the simplicity of the procedure, in many aspects the results are quite comparable to those of the full-blown detector simulation program.

SGV simulates colliding beam detectors in a solenoidal magnetic field, ie. such as eg. the detectors at LEP, those at the Fermi-Lab $\bar{{\rm p}}{\rm p}$ collider, those at the future LHC at CERN or those at a future linear electron-positron collider, among others.

The detector is described as cylinders with a common axis, parallel to the magnetic field, and as planes perpendicular to the common axis. The cylinders are described by their radius and minimum and maximum extent along this common axis. The planes are described by their position along the axis and their minimum and maximum radius. In addition, the material, the thickness in radiation lengths, and the type and precision of measurements are also given. Each cylinder or plane can be divided in repeating sectors of measuring and non-measuring parts, so that eg. blind sector-boundaries between detector sectors or over-lapping detectors can be simulated.

Cylindrical and plane calorimeters can be specified in a similar fashion. The geometry is given in the same way, while the energy resolution and the shower axis measurement precision are given by parameters.

For each charged particle generated by the bare physics simulation (which can be selected at will by the user) which is either stable or decays weakly, SGV calculates which of the tracking-detector surfaces the track helix intersects. From the list of those surfaces, the program analytically calculates the precision with which the parameters of the track can be measured. This calculation includes the multiple-scattering in the traversed surfaces, and the measurement precision at each surface that measures the track position.

Each particle (neutral or charged) is also followed to its intersection with the calorimeters. The program determines which one the particle hits first (ignoring electro-magnetic calorimeters if the particle is a hadron), and using the parameters to simulate the measured energy and the direction of the shower in the detector. Optionally, the program can also merge showers that are so close together, that they would be hard to distinguish in a real detector.

Optionally, the most important electromagnetic interactions in the detector can be generated, ie. brems-strahlung from electrons and production of ${\rm e}^{+}{\rm e}^{-}$ pairs from photons.

The user can supply routines to simulate inefficiencies and particle identification.

An option in the program is that rather than delivering the track-parameters with experimental errors added, the coordinates of each intersection with detector elements can be given. This constitutes an excellent tool for testing and developing soft-ware for track-finding and fitting. This is a rather hard task with a complete detector simulation, because of the wast amounts of data that must be output if the simulated rawdata must be accessible outside the program. In addition, it is often hard to ascertain if a given solution is correct or not.(NB. The code to produce hits is under revision and is NOT included in the present release of SGV).

In the design of SGV, we kept in mind that the analysis code developed by the user should be easy to transport to an other environment, eg. the analysis program of the experiment. This was accomplished by sealing of the analysis part of SGV as a separate object, which the rest of SGV need not to know the internal workings of, nor vice versa. Hence, one can develop an analysis 'at home', write a small interface routine that reads the experimental data and formats it according to the specifications for the input to this analysis-object, and then use exactly the same analysis code on real data, or on data simulated by the full detector simulation.

We also considered the fact that, unlike most others, the user-community of particle physicist is quite fluent in programing. Hence,it is a large waste of human resources to write a program aimed at such a community as a non-transparent 'black box'. Therefor, SGV was written to be accessible for modifications at all levels, by keeping the structure clean and by extensive documentation all the way down to the individual routines. This consideration also left only one program language to consider, namely FORTRAN. Since thorough knowledge of system programing is less abundant in the community, we also wrote the program such that it is self-installing on the most popular systems, ie. VMS and various flavors of UNIX.