Simulation meeting, 8:30am PDT, Aug 12, 1996

Attendees:

Hwanbae Park         303-492-2031
Patricia Rankin      703-306-1898
Bob Jacobsen         510-527-1927
Bill Lockman
Torre Wenaus         209-982-5603

Meeting notes

Review of the TRIUMF Geant4 workshop, Aug 2-9

General impression: Geant4 design is in very good shape, implementation is generally progressing well but geometry is a concern, as is tracking in magnetic field. Amount of work to be done before the next milestone -- March '97 -- is large. So is the distance the project has come. Geant4 is 180k lines of code (generously counted); Geant3 is (including everything) 220k. (The complete Geant4 will be nowhere near 220k lines!)

Priorities during the second half of '96:

• CSG (Geant3) geometries
• tracking in magnetic field
• multiple scattering
• geometrical tracking (handling boundaries)
• persistency

The meeting consisted of plenary sessions (presentations and broad design discussions) and working sessions (coding and detailed design). It was effective in presenting the broad state of the project, many concrete design decisions were made, and even some real coding got done. In the following some of the main points in each of the areas of discussion are covered, with an emphasis on those relevant for BaBar.

TRACKING

- big open item: tracking in magnetic field
- some design optimization has been done in light of physics work and
  rethinking of the stepping structure
- G4Step class designed. Provides info needed by stepping. eg. a G4Step
  object is passed to the Pre-, Post- SteppingAction objects to provide
  user access to the step
- actual tracking mechanism is not a problem; Runge Kutta tracking in a
  field has been prototyped and benchmarked and is well known from G3
- problem is in the design of the two-stage process:
  - calculate the step distance in the presence of variable magnetic
    field (and, possibly, integrated multiple scattering)
  - perform the step
- current G3 approach:
  - calculate the step distance using full R-K calculation of distances
    to volumes
  - perform tracking along calculated R-K path
    - safety (distance to nearest boundary) not looked at at all
    - at end of track propagation, check whether endpoint is still in
      the same volume. If not, divide path length by two and re-propagate
      - there is no assurance thin volumes will not be skipped
      - max angle of deviation tries to avoid skipped volumes, but this
        translates to a step size limit which impacts performance
    - this approach in Geant4 would imply, in the general case, a R-K
      path calculation to a NURB (complex volume) at every step
    - REJECTED for performance reasons
- previous G3 approach:
  - safe bounding box is determined with fast safety calculation
  - bad for rectilinear paths nearly parallel to boundaries. Safety is
    very small, resulting in many very small steps; an appreciable
    inefficiency in many geometries (eg. nearly projective crystal
    calorimeters).
  - REJECTED for performance reasons
- NEW approach:
  - a new approach has been developed which supplements the isotropic
    (spherical) safety of the old Geant3 approach with a 'cylindrical
    safety' to cover the case of propagation parellel to boundaries
  - isotropic safety PLUS a cylindrical safety along a rectilinear path
    in the direction of the particle. Radius of the cylindrical safety
    is determined by the distance from the rectilinear path of the
    volume closest to the path
  - Geant4's 'smart voxel' virtual volume generation ensure one
    tracking step doesn't involve a large number of volumes, which could
    result in very small cylindrical safety (eg. for a drift chamber
    with individual wire volumes)
  - isotropic safety and cylindrical safety are quick calculations
    (with the price being they are approximate and conservative)
  - in the case of parallel tracking along a boundary, the cylindrical
    safety determines the step, much larger than in the old scenario
  - bottom line:
    - approach is in place (not coded), no big holes in it yet
    - if none appear in next few weeks, solution is on track
    - but won't be quick. March deadline.

Fast simulation:
- tracking/stepping design fleshed out and reworked to accommodate
  fast simulation
  - G4UserSteppingAction converted to pre-step and post-step actions
  - new method(s) specifically devoted to parametrized treatment endorsed
    - no design yet; I will implement my proposed design and present
      at CERN in Sept
  - UserAction class inherited by user to build tracking control
    objects
  - concept of everything required for a detector description hanging
    from Volume seems to be endorsed, may require fleshing out (Volume
    largely off the map of this workshop; addition of SensDet achieved)
    [I have my doubts this will work, and we may need our own 'detector'
    class that aggregates classes defining a detector]

HADRONICS

  - division of work:
    TRIUMF: 3 GeV down
    Fesefeldt: 20 GEV up
    3-20 GeV: straight conversion of GHEISHA and no plans for improvement

    TRIUMF work:
    - program of work:
      - convert existing GHEISHA code
      - then work on improvements of parametrizations modelling. Many years
        data since original work.
    - G4CrossSectionTable abstract class for general use.
    - 'to implement one channel, inherit from one class and implement one
      aggregated class for the desired channel'
    - incident proton cascade currently underway; then about 20 other.
      [ interest in farming out cascades, eg. pi?]
    - attention given to designing for user introduction of code
    - conversion of GHEISHA code about 50% complete
    - careful work on G3/G4 comparison. Converted codes agree well so far,
      testing incomplete.
    - new Cerenkov radiation code in development. C++ adaptation of G3 code
      followed by improvement/extension. Usefully exposed Geant4 design issues.
      Other implementations by detector groups may be done, but with this
      implementation Geant4 offers the basics, and profitably exercises the design
  - will support changing of type of particle at track start; eg. user control of
    charged/neutral pion ratio for calorimeter response tuning
  - another interesting idea: adjusting the detail of geometry description used
    during tracking to the particle type (eg. pion sees cruder geometry than
    electron).

EM

HITS/DIGI

- new hits design reviewed and agreed upon
  - G4VSensitiveDetector can use either tracking geometry or specialized
    simpler (reconstruction?) readout geometry. An abstract class.
  - hierarchies of hits eg. reflecting readout segmentation supported
    via G4SDStructure. Address of a hit is reflected in its position in the
    hierarchy rather than a flat ID
  - multiple hit collections supported
  - hit definition in complete control of user, via inheritance of
    abstract class
  - new design implemented at the workshop
    - benchmarks and test detector implementations over next 2 mos.
    - G3toG4 implementation in Sept
  - capable of supporting DC approach of analytic DC model doing its
    own MS off wires. Control stepping to wire loc'n, cell boundaries,
    and invoke G4's MS physics
  - digitization not included in present design
    - how important? Need something, but probably not used by BaBar
    - our requirements will be supported:
      - multi-stage digitization: digi source either hits or digis
  - hits/digi is the testing ground for Objectivity-based persistence
    - division of run-, event- based storage. G4Run, G4Event classes
      run: sensitive detectors, geometry, etc.
      event: HitsCollections, random numbers (in G4Event)
    - capability to change geometry, readout during run (eg. alignment,
      dead regions)
    - work underway with RD45
    - something available by year end

PIIM (Physics Interactions In Matter)

- redesign of the physics process classification was done
  - from Cont (ioniz), Semi-Cont (Cerenkov), Discrete (brems) to more
    general architecture without these constraining pigeonholes
    - 5 'entry points' in the stepping needed by different types
- dynamic particle able to see (and override) the process manager; full
  step-level 1-track control of physics processes used (eg. DC app)
- implementation approach of Cerenkov accepted, special optical properties
  classes available to any physics process
- implementation common ground in common G4PhysicsTable
- very nice units design accepted
- share process classes between particle types

GRAPHICS

- basic architecture of graphics presented and endorsed
- little exists now in the way of usable graphics; largest part of work has
  been in the foundations
- no X-capable display presently available. Now recognised as an important
  deficiency, and given a high priority.
- raw OpenGL work in progress. General problem: tools in use to date have
  been too low-level
- Open Inventor work just starting; FNAL (with experience and intent) were
  there as observers.
- potential design problems?
  - multiple representations of graphical objects, eg. hits represented as a
    simple 'dot' in a full-detector display but, in a zoomed view,
    as a 3D object with features (size, shape, normal direction) characterizing
    the hit
  - design only allows one active representation (set of 'displayed elements')
    of a detector, but you may want different components to be displayed
    depending on scale, eg. SVT displayed in a full-detector plot or zoomed

GEOMETRY

GENERATORS

New date for the review

Next meeting