This README file describes the structure of the simulation 
of the BABAR electromagnetic calorimeter in BBSIM.


GEOMETRY:

The basic geometry description is contained in file emca.db.
Its parameters are used to build all GEANT volumes to describe 
the calorimeter. 

Key routines for setting up the geometry are:
   em_volu --> emx_vol --> emx_npvol --> emx_npc
where x = b,e for barrel, endcap, respectively.
They implement a modular, non-projective geometry that reflects
almost all the details of the latest engineering design; missing
pieces will be described below.
The algorithm to calculate the crystal dimensions is an adaptation
of the one used to specify them for the manufacturers; see also
README_nonproj_geometry.
(For backward compatibility, emx_vol still contains the functionality
to set up a non-modular, fully projective geometry as it was used for
the TDR simulations.)

The volume structure for the barrel is (from emb_npvol):
!     EMBS - (PCON/ONLY)Shielding volume which also serves as mother volume
!     EMBA - (PCON/ONLY)Mother volume of barrel, placed inside EMBS.
!     EMBP - A modular subdivision (in phi) of EMBA.
!     EMBM - (PCON/ONLY)Module mother volume
!     EMBN - Crystal-level subdivision of EMBM
!     EMBE - (TRAP/MANY)A crystal enclosure volume, placed into EMBN
!     EMBC - (TRAP/ONLY)Live crystal volume

The volume structure for the endcap is (from eme_npvol):
!     EM1S -   (PCON/ONLY)Shielding volume which also serves as mother volume
!     EM1M -   (PCON/ONLY)Mother volume of endcap, placed inside EM1S. Extent of
!            of overlap determines shielding thickness.
!     EM1P -   A modular subdivision of EM1M, boundaries will give module walls.
!     EMSA,B,C (PGON,ONLY)Theta Superlayer module mother. 
!     EMPA,B,C  crystal-level subdivision of EMSA,B,C
!     EM1E -   (TRAP/MANY)A crystal enclosure volume, placed into EM1M.
!     EM1C -   (TRAP/ONLY)A crystal volume, placed into EM1M.

Missing from the geometry description are many of the details of the
material _behind_ the crystals, including readout boxes, cables, bridge
plates, and strong backs. This is not critical at the moment, but
should be implemented in the long run to improve the realism of studies
using the IFR.

The current scheme for setting up the geometry does not allow for an
easy implementation of any non-ideal properties of _individual_
crystals, including  dimensions, positions, and non-uniform light
collection. Those might be dealt with via the conditions database
when reconstructing simulated data.

HITS:

Hits are generated in em_step if their energy (DESTEP) in an active
volume, i.e., crystal, exceeds 1eV.
A hit consists of seven elements: x, y, z, crystal index, time,
weighted energy, and energy. (The weight can be a function of x,y,z;
currently it is identical one.) 
Hits are stored with GSCHIT in such a way that the last two elements,
i.e., weighted energy and energy, are accumulated; for the other
elements what gets stored is the information from the _last_ hit
associated with a track.
The hit structure is (from emca.db):
!   number of hit elements
  dimension nhel_emca 7  
  index emht  /
     X       Y       Z      IDNT   T       EDEW   EDEP
!   hit name
  char hnam(7)     /
    "X"     "Y"     "Z"    "IDNT" "T"     "EDEW" "EDEP"
!   hit number of bits
  int nhbit(7)     /
    16      16      16     16     32      32     32
!   hit ORIG, the offset
  real orig(7)     /
    200.    200.    200.   0.     0.      0.     0.
!   hit FACT, the precision
  real fact(7)     /
    1.e2    1.e2    1.e2   1.e0   1.e10   1.e7   1.e7

DIGIS:

Digis are created from GHits by the EmcSim module in the Framework.
This module does a detailed simulation of the feature extraction
as a function of energy and time of the GHit. Digis carry a pointer
to the parent GHit. This simulation also handles the case of multiple 
hits in a single crystal.
The detailed simulation will be used to develop a less time consuming
parametrization of the effect of feature extraction; the parametrization
is what has to be used in high-statistics MC production.

FUTURE PLANS:

The goal is to build the most detailed calorimeter simulation possible.
If in the process the simulation becomes unacceptably slow, it will be
used to derive less time-consuming parametrizations.

Most likely, the Framework is the place where individual crystal
behaviour, e.g., noise, calibration, alignment, will be dealt with.
To that extent, progress in improving the level of detail in the
_simulation_ is tied to progress on the _reconstruction_ infrastructure.

A major clean-up of the gnemca package is underway to remove various
implementations of obsolete geometries, and to remove entirely the
calorimeter reconstruction from BBSIM; this work is almost finished.

At the moment, release validation is done ``by hand''. It is realized
that this will need to become a more/fully automated process.

Progress in all areas is limited by manpower, but that will never change.


ASLUND:

The BBSIM geometry is used to automatically generate the ASLUND
input file EMC.input. This will ensure that the ASLUND _geometry_
always stays in sync with the one in BBSIM. However, equally important
are ``realistic'' parametrizations of the calorimeter energy and angular
resolutions using that latest BBSIM model; this work is still in progress.