gtouchable
Loading...
Searching...
No Matches
gtouchable module

Overview

The gtouchable module provides a compact representation of a sensitive detector element that can be used as a key when building and merging hit collections during digitization.

A GTouchable is uniquely described by:

  • A list of identifiers (the identity vector), e.g. "sector: 2, layer: 4, wire: 33".
  • A discriminator rule that depends on the touchable type (readout/flux/particle_counter/dosimeter/integral_counter).

Conceptually, a touchable is the “address” of a detector element plus the extra context required to decide whether two hits belong to the same readout cell (and therefore can be merged).

Main detector types

The module supports the following touchable types:

  • readout : electronic time window is the discriminating factor in addition to the identity vector.
  • flux : track id is the discriminating factor in addition to the identity vector.
  • particle_counter : particle id is the discriminating factor in addition to the identity vector.
  • integral_counter : the identity vector is enough (no additional discriminating factor).
  • dosimeter : the identity vector is enough (no additional discriminating factor).

Available Options and their usage

This module currently does not define or consume any module-specific option keys.

Notes:

  • The module participates in the standard logging configuration via TOUCHABLE_LOGGER.
  • Global keys defined by GOptions(argc,argv,...) (e.g. verbosity, debug) may influence logger behavior for this module, but no runtime configuration keys are read by the data structure.

Examples

gtouchable_example.cc

Demonstrates:

  • Constructing a GTouchable from an identity string.
  • Creating test touchables with GTouchable::create().
  • Comparing two touchables using operator== and logging the result.

Source file:

Ownership and extension points

  • Ownership: This module is part of GEMC and is maintained within the GEMC codebase.
  • Extension points: The rules that assign readout timing, energy multipliers, and other digitization-dependent attributes are typically implemented in digitization plugins. This module focuses on the data structure and comparison semantics used by the hit processing pipeline.

Verbosity and logging

The module uses the GLogger infrastructure via the logger name "gtouchable" (see TOUCHABLE_LOGGER). Typical verbosity behavior:

  • Level 0: important messages only (rare in this module).
  • Level 1: high-level informational messages for normal workflows.
  • Level 2: detailed informational messages, typically used for validation and troubleshooting (e.g. existence checks).
  • Debug: step-by-step internal diagnostics (e.g. constructor traces and per-identifier comparisons).
Author

© Maurizio Ungaro
e-mail: ungar.nosp@m.o@jl.nosp@m.ab.or.nosp@m.g