Corinna Catterall 21/10/2002

What is Mozart? Mozart and Geant Geometry, Tracking and Digitisation The Geometry GAF System Some History... Ongoing development Interactive Visualisation Mozart and Funnel

UnderstandingUnderstanding

What is Mozart?

Mozart is the ZEUS detector simulation program -- an extensive suite of software in a continual state of evolution.

Mozart has an input interface to Amadeus (ZDIS) for events from physics generators.

Mozart utilises the CERN Geant software package to provide Geometry (shape, material and position of detector components)Internal generation of simple events Tracking (propagation of particles through the whole detector taking account of processes such as particle decay, energy loss, multiple scattering and the effect of the magnetic field).

Mozart provides Adamo digitisation with output interfaces to "MCTRUTH" -tables containing true (Geant or Generator) values for hit, track and event parameters Raw data -the same tables as are used in real data, filled after simulating detector resolution effects

Mozart Components and Features

Mozart is essentially an extended user interface to GEANT.GEANT provides facilities for the user (Mozart) to:

describe an experimental setup by a hierarchical structure of geometrical volumes: A medium number is assigned to each volume by the user. Different volumes may have the same medium number. The definition of a medium includes reference to the material filling the volume ; accept events simulated by Monte Carlo generators; transport particles through the various regions of the setup, taking into account geometrical volume boundaries and physical effects according to the nature of the particles themselves, their interactions with matter and the magnetic field,record particle trajectories and the response of the sensitive detectors visualise the detectors and the particle trajectories.

Mozart and Geant

GEANT provides dummy and default user subroutines called whenever application-dependent actions are expected. The names of the dummy or default user subroutines have GU or UG as their first two letters.

It is the job of the user (Mozart) to: code the relevant user subroutines providing the data describing the experimental environment; assemble the appropriate program segments and utilities into an executable program; Compose the appropriate data records which control the execution of the program.

Mozart and Geant

How does this work in practice?........

GEANT : A Simplified Flow Chart

GEANT GEOMETRY -- Some Basic GEANT Shapes

GEANT Geometry -- Putting the shapes together...can be complicated

MVD X-Y CUT

2002 REARBEAMPIPE REGION

Y-Z CUT1995-2000BEAMPIPEWITHCOOLING PIPES

PIPE

GEANT Geometry -- Hierarchical volumesPart of Mozart's HERA tree....

HERACOIL

BPRE

BCAL

CTD

FCAL

RCAL

PIPU

GEANT's DTREE representations of the HERA and PIPE volumes

A Word of Caution......

GEANT will happily let a user load "buggy" geometry, and run with no complaints, while giving quite different results from what the user intended!

A A

B B C1

D

C2

DC1

C2

e.g. D is bigger than its mother B!! D also overlaps C1.

The Geometry GAF System

Geometry GAFs are static ADAMO databases containing the information (dimensions, positions, rotations, materials, media, detector sets) required by Geant to set up the geometry of ZEUS and its components.The MaterialsAndMedia and RotationMatrices dataflows are (almost) year-independent and are globally accessible to all ZEUS components. The dimension, position and sensitive detector information is contained in pairs of component-specific dataflows, e.g.BMPGeometry1, BMPGeometry2 (Beampipe)CTDGeometry1, CTDGeometry2 (CTD)They have a series of version-dependent validity periods corresponding to changes in geometry configuration for different run periods.

For every volume declared to be a sensitive volume (ISVOL=1)the Geant user routine GUSTEP is called at each step during the propagation of a particle through that volume. This gives the user the opportunity to insert its own code to record detector hits.In Mozart's GUSTEP this task devolves to the component detectors, which are identified to Geant by SETs of active DETectors.

Digitisation

#if ( defined(CF__MVD) ) ELSE IF (IUCHAR.EQ.'MVST') THEN CALL MVDSTEP#endif#if ( defined(CF__CTD) ) ELSE IF (IUCHAR.EQ.'CTST') THEN CALL CTSTEP (*100)#endif#if ( defined(CF__FRTD) )C ELSE IF ((IUCHAR(1:3).EQ.'FTD').OR.(IUCHAR(1:3).EQ.'RTD')) THENC FTD OR RTD DATA ACCUMULATIONS ARE DONE FROM FTSTEP CALL FTSTEP#endif

Digitisation

At each of GEANT's tracking steps, the hit data may be stored in GEANT's bank structure (JHIT), but more often in Mozart they are entered directly into ADAMO tables.At the end of each event Geant provides two user routines, GUDIGI and GUOUT. Again, ZEUS bypasses the GEANT bank structure and uses ADAMO. In practice, the various ZEUS components call their own event-processing routines from either one or the other or both of GUDIGI and GUOUT, in whichever way it suits them.At this stage, the components can be quite autonomous, because there's little possibility for their digitisation to affect anyone else's. (This is not the case with the geometry!)The guiding principle is that each component should output (in addition to the truth tables) raw data tables that are identical to those from the real ZEUS detector.

Some Mozart History....."A camel is a committee's attempt to design a horse."

To understand the idiosyncracies of Mozart, it helps to know something of its history.Much of Mozart's current style arose from the welding together of two independent concepts of ZEUS detector simulation software, informatively named the Trigger Monte Carlo and the Bologna Scheme respectively. Mozart has since passed through several hands and has undergone further stages of evolution, including conversion to from PATCHY/CMZ to ZSMSM, and adaptation from Geant 3.13 to Geant 3.21.Various new components have been added over the years. Modifications are ongoing, reflecting changes made to the real-life detector and our improved understanding of it.

The Trigger Monte Carlo

This did not simulate the trigger! (That is now done by the CZAR/ZGANA software). The Trigger Monte Carlo (G. Hartner, Y. Iga) was a full GEANT simulation of the entire ZEUS detector. Its name came about because it was used to generate beam-gas and DIS data for trigger optimisation studies, before HERA came on stream.

The Trigger Monte Carlo featured electromagnetic and neutron shower terminators (EMTERM and NUTERM). These intercept the low-energy components of Geant's EM and hadronic shower simulations and substitute faster parametrised processes, tuned to reproduce the test beam measurements for the ZEUS Uranium calorimeters. (Geant's default processes were not only slow but gave the wrong answers for UCAL showers.)

The Trigger Monte Carlo took a conventional GEANT approach (non-ADAMO) to geometry setup and hit storage.

The first Trigger Monte Carlo version, ZG311T1 (ZeusGeant3.11+showerTerminators), was released in April 1988.

The Bologna Scheme

The "official" ZEUS Monte Carlo at this time was ZeusGean (A.Tenner) which introduced many of the basic administrative structures of Mozart, such as the LHECA array for components' "geometry" and "hits" control cards.

Meanwhile, an ADAMO interface to Geant was developed by the Bologna group (A.Bassi, R.Nania,...). It featuredGAF storage of GEANT geometry values (volume dimensions, positioning, materials, media.......)GAF storage of GEANT particle typesGeneric interfaces to GEANT geometry routines.ADAMO storage of GEANT hits (bypassing GEANT's banks).

MERGEDMC (Controlled schizophrenia?)

For a while, these endeavours coexisted and competed. Eventually the Bologna Scheme, with its ADAMO functionality, was merged into the framework of the Trigger Monte Carlo and its shower terminators. The full merge of ZG313T4 was completed in September 1992, by Yoshihisa Iga and Norman McCubbin, while Yoshihisa Iga was Mozart editor. Norman McCubbin created the semi-automatic GAF-maker, which generates the Bologna-style geometry GAFs by parsing the Fortran code containing the calls to GEANT. Most components now have two alternative versions of their geometry routines, selectable at compile-time by the switch MERGEDMC:The TRIGMC version (MERGEDMC inactive) contains the component's

master code from which the GAFs are derived. It is used for development.The MERGEDMC version (MERGEDMC active) reads the component's

geometry values from the GAFs, and passes them to GEANT by means of generic interface routines. It is used in normal Mozart running, e.g. Funnel.

Further Evolution 1996-2002

During 1995-6 C.Catterall took over from Y.Iga as Mozart editor. Since the merge of ZG313T4, Mozart's GEANT interfaces, including the

shower terminators, had been tuned to work with GEANT 3.13. GEANT, meanwhile, had continued development until version 3.21, when it froze it's Fortran code and began work on GEANT 4 in C++.

GEANT 3.21 included some significant advances, including greater flexibility with geometry, improved simulation of physics processes and, most notably, striking and user-friendly interactive graphics capabilities.

In 1996, F. Pelucchi began work on adapting Mozart for use with GEANT 3.21.An additional compile-time switch was introduced, G321, to select the Geant 3.21-compatible code.

For the simulation of 2002 and later, it was decided to abandon the Geant 3.13 option and move completely to Geant 3.21.

In 1997 Mozart was converted from PATCHY/CMZ format to ZSMSM by John Ryan.

Current Mozart Build Options under ZSMSM

The Mozart library build options (targets for make) are now:lib_mergedmc_g321 : $(MAKE) lib MERGEDMC=ON G321=ON GEANTVERS=321a

lib_trigmc_g321 : $(MAKE) lib MERGEDMC="" G321=ON GEANTVERS=321a

lib_mergedmc_g313 : $(MAKE) lib MERGEDMC=ON G321="" GEANTVERS=313

lib_trigmc_g313 : $(MAKE) lib MERGEDMC="" G321="" GEANTVERS=313

There are three additional switches for the exe build, INTER (interactive Geant graphics), DEADM (dead material map), and GAFMAKER.The Mozart exe build options are:

exe_mergedmc_g313 : $(MAKE) exe MERGEDMC=ON INTER="" G321="" GEANTVERS=313

exe_trigmc_g313 : $(MAKE) exe MERGEDMC="" INTER="" G321="" GEANTVERS=313

exe_mergedmc_g321 : $(MAKE) exe MERGEDMC=ON INTER="" G321=ON GEANTVERS=321a

exe_trigmc_g321 : $(MAKE) exe MERGEDMC="" INTER="" G321=ON GEANTVERS=321a

exe_mergedmc_inter : $(MAKE) exe MERGEDMC=ON INTER=ON G321=ON GEANTVERS=321a

exe_trigmc_inter : $(MAKE) exe MERGEDMC="" INTER=ON G321=ON GEANTVERS=321a

exe_gafmaker: $(MAKE) exe MERGEDMC="" INTER="" G321="" GEANTVERS=313 GAFMAKER=ON

exe_deadmap_g313: $(MAKE) exe MERGEDMC=ON INTER="" G321="" GEANTVERS=313 DEADM=ON

•exe_deadmap_g321: $(MAKE) exe MERGEDMC=ON INTER="" G321=ON GEANTVERS=321a DEADM=ON

Ongoing Development

Mozart development will continue as long as ZEUS remains in operation. Changes that are made to ZEUS from year to year are simulated.Bugs are found and fixed.Improved understanding of the detector feeds back into

improvements to the simulation.Usually about 2-3 Mozart versions are released per year.Recently then emphasis has been on simulating the HERA-Upgrade configuration of ZEUS, including the new detectors. Even more recently the emphasis has been on simulating the HERA-Upgrade background and possible measures to reduce it. Changes to Mozart, made by component experts, etc., as well as any requests for changes, are passed to the Mozart editor for inclusion in the next Mozart release, and from there into Funnel.

Interactive Visualisation

The interactive graphics uses the main program GXINT instead of ZEKKUS. GXINT calls GPAW which initialises HIGZ and PAWC as well as the usual Geant ZEBRA banks.Only the main program differs; the other user-hook routines are the same as in the regular Mozart -- so no special Mozart library is needed. It can be built in either TRIGMC or MERGEDMC mode,but is only available with GEANT3.21, not with GEANT3.13.

To build an interactive graphics executable, first build the Mozart G321 library in the usual way (if it doesn't already exist) withmake lib_trigmc_g321 or make lib_mergedmc_g321then build the executable withmake exe_trigmc_inter or make exe_mergedmc_inter

Interactive Geant Screenshot

Examples of Interactive Graphics

BOX CUTTHROUGH ZEUS

PERSPECTIVE VIEW OFBCAL

DIS EVENT IN ZEUS

Mozart and Funnel

Trigger Simulation:

CZAR

ZEUS Data

Storage

Reconstruction:ZEPHYR

ZEUS Physics Analysis

environment

Event Generators:Amadeus,ToZDIS

Analysis:EAZE,

Orange....

Detector Simulation:MOZART

The Funnel ChainThe Funnel Chain

Funnel Site Administration,

QueueManagement...

The real world,HERA, ZEUS,..

FLT, SLT, TLT

Mozart and Funnel

Mozart is one link in the Funnel chain.

When a new Mozart version is ready for release,

the process of building a new Funnel version is just beginning

Some GEANT and Mozart References

GEANT (CERN Long Writeup W5013; Application Software Group, Oct. 1994 Ed.) ZN 88-049. MC Shower Terminators for ZEUS inside GEANT311. (G.F. Hartner)ZN 90-084. ZEUS Trigger MC Program Status. (G.F. Hartner and Y. Iga)ZN 94-149. Simulation of the ZEUS Calorimeter. (Y. Iga)DESY 95-005. Simulation of the ZEUS Calorimeter. (Y. Iga)ZN 96-016. Improvement of Electromagnetic Shower Profile Simulation of the RHES. (T. Matsushita et al.)Adaption of MOZART code to the 3.21 GEANT version. (F. Pelucchi)ZN 97-019. Status and Improvements of the ZEUS Calorimeter Simulation. (Y. Iga and S. Schlenstedt)ZN 98-077. Improved Simulation of Hadronic Cascades in the Uranium Calorimeter. (C. Catterall and Y. Iga)