1 of 16

Detector Geometry Interface

Implementation

Andrea Dotti (adotti@slac.stanford.edu) ; SD/EPP/Computing

​

Document: https://gitlab.com/ESC/documents

http://www.geant4.org

2 of 16

Introduction

3 of 16

Proposed Work Plan

  • Identify a task-force to elaborate on this plan more in detail, defining timelines, goals and deliverables and evaluating work-loads and manpower needs: Jason Webb, Jerome Lauret, Alexander Kiselev, Dmitry Arkhipkin, Markus Diefenthaler, Maurizio Ungaro, Andrea Dotti
  • Identify the three most common hits data structure for NP detectors: tracker, TPC and and calorimetric hits.
  • Define a prototype data structure for these hits types. Investigate which technology can be used to define persistency formats.
  • Define prototypes of associated reader/writer that are independent of Geant4 but that can be added to Geant4 and ROOT applications.
  • Milestone 1: Make this prototype code public in our gitlab repository.
  • Demonstrate that the hits handling in this schema are technology independent creating: a writer for Geant4, a reader for ROOT and a reader for SciPy/NumPy.
  • Milestone 2: Demonstrate that identifiers created in this way satisfy the needs of reconstruction.
  • Demonstrate that the code needed for the previous points is simple enough that we can maintain it with minimal effort.
  • Decide if, at least for the time being, GDML is the geometry-exchange format for EIC R&D. We should demonstrate that some of the existing frameworks are able to export their current geometry in GDML.
  • Milestone 3: Demonstrate that we can export to GDML the information about the identifiers of SensitiveDetectors using current GDML schema.
  • Define a strategy to link generator truth information to hits. How to make this information persistent?
  • Milestone 4: Choose one of the existing NP frameworks/applications and demonstrate that we can easily port it to the output of this work.

​

4 of 16

Recap of discussion so far

Describe geometry in terms of shapes, materials and (hierarchical) structure is not enough

​

Main issue is how to associate Sensitivity and exchange this information between applications/detectors

​

Start with GDML

​

Already available: examples/extended/persistency/gdml/G04 : “Simple example showing how to associate detector sensitivity to a logical-volume, making use of the auxiliary-information.”

​

​

5 of 16

Some definitions first

What is a G4Hit and what is a Sensitive Detector?

​

Geant4 performs simulation in steps: the atomistic-unit of the simulation: two (ordered) points in space, with associated energy deposit. One and only one track is associated to any given step. At any given moment during the simulation only one step exists in a Geant4 application (the current step)

​

A (Geant4) hit is a way for the user to make this information persist for the duration of an event, see: Geant4 Application Developers Manual chapter 4.4 Hits are organized in collections of the same type (e.g. c++ class), and SDs are responsible of creating and filling one or more collections

6 of 16

Consequences

A G4Hit is not the response of the detector (e.g. pulse shape, digital output, response of a PMT)

In Geant4 the concept of G4Digit is used for this (limited use)

However often some low-level detector effects (Birks’ saturation, some zero suppression) are included in hits for convenience

​

A SD a relatively simple algorithm that transforms the G4Step in a G4Hit

​

With some detectors (e.g. calorimeters) it is impractical to transform each single G4Step to a hit (too many), thus accumulation is preferred (e.g. one hit per calorimeter cell, that accumulates all energy deposits)

7 of 16

Moving forward

8 of 16

Proposal

​

  • Identify the common typical “hits” of EIC detectors
  • Create detector independent SD and hits
  • Leave to the detector specific frameworks: hits→digits
  • Use GDML to specify the SD and hits naming convention
  • Allow for I/O hits in files

9 of 16

Hits

Define three types of hits (names to be changed):

​

  • Tracker hit: the persistent representation of a single G4Step
  • Calorimeter hit: the summation of all energy deposits in a given space
  • TPC hit: I understand this is somehow in the middle of the two

​

A hit is identified by a key

The key is unique given an event and a collection

Does not have to be a number (e.g. a tuple, an hash, a name)

10 of 16

Managing Hits

Once the hit structure is defined, SDs make the mapping

​

Develop simple and generic SDs that can create these hits. This could be used as a starting point for a new detector-specific developments or used directly without modifications

11 of 16

Geant4 integration 1

With this approach, SDs and Hits become detector independent, a stand-alone library will be created

Based on example G04: should show how to integrate w/ GDML. Any framework/detector (+our library) should be able share GDML

​

An optional part of the library could also provide a way to write out hits in files (options: ROOT, gprotobuf, HDF5, ASCII, …)

​

Note: hits file are not self-describing, one needs the GDML to be able to do reconstruction (e.g. same calorimeter hits with two different inner detectors)

12 of 16

Geant4 integration 2

Starting from Geant4 10.3 (2016), it is possible to have multiple SD associated to a single (logical) volume

​

Add our SDs to an existing detector preserving existing code

13 of 16

What should be in a hit: “tracker”

ID

Int

Volume ID(s)

[]*sizeof(int) OR []*string

PreStepPoint {x,y,z,t}

4*sizeof(double)

PostStepPoint {x,y,z,t}

4*sizeof(double)

ΔE

1*sizeof(double)

PDG code

sizeof(long) //needed for ions

Truth {Px,Py,Pz,E}

4*sizeof(double)

​

896B + IDs

We can talk about space optimization later (e.g. save one time in double and Δt in float, direction angles and step length in float)

14 of 16

What should be in a hit: “calorimeter”

ID

Int

Volume ID(s)

[]*sizeof(int) OR []*string

Characteristic space Point {x,y,z}

3*sizeof(double)

Min t and Max t

2*sizeof(double)

At least one ΔE (for time info needs to distinguish late hits)

>1*sizeof(double)

PDG codes? All, only for ΔE>min{threshold,0}

>1*sizeof(long) //needed for ions

Truth {Px,Py,Pz,E}? All only one for ΔE>{threshold,0}

>4*sizeof(double)

​

>704B + ID

The idea is to have hits independent of detector effects (e.g. no cut on t), to be able to reprocess hits with different “detector electronics setups”. But we could allow to have simplified hits with less information (e.g. fixed time cut)

15 of 16

Calorimeter hits

Much more challenging because they depend on how the detector is defined (e.g. calorimeters cell structure)

​

As a first step we could implement the “tracker” hits, that are logically simpler

​

Possibilities:

  • Forget about file dimensions and use “tracker hits” also for calorimeters. ~OK for some initial testing
  • “pseudo” cell divisions: e.g. a calorimeter SD has its own segmentation that does not have to match the real one

​

Remember: the idea is that complete applications keep their existing systems

​

16 of 16

Locating a step: and write in hit this ocation

The input to an SD is a G4Step, one can locate its position in a detector-independent way:

​

​

​

auto point = aStep->GetPreStepPoint();

auto touchable = point->GetTouchable();

int copyN = touchable->GetCopyNumber( depth = 0);

int replicaN = touchable->GetReplicaNumber( depth = 0);

/*

auto physvol = touchable->GetVolume( depth = 0);

auto lv = physvol->GetLogicalVolume();

const G4String& name = lv->GetName();

*/

​

Loop on depth to “climb”

geometry hierarchy