Hitprocess

Introduction

output banks and related hitprocess in GEMC, refer to clas12 as example

• The output banks are stored in database "solid_banks". The bank scripts and definition files are in svn "database_io/solid/banks/"
  • "solid_hits_def.txt" defines the hit processing table "SDId" for all banks.
  • run "go_hits solid_hits_def.txt bank_database" to update the table "SDId" in bank_database.
  • "bankdefs/*.bank" defines bank variables "name, id, type(1 double, 0 int), activated(1 on, 0 off), description"
  • run "go_bank bank_database " to update all banks in individual tables found in bankdefs directory

• The hit process c++ class are in svn "hitprocess/"
  • "HitProcess_MapRegister.cc" registers all type of processes which can be assigned for different experiment.
  • "solid/*_hitprocess.cc" handles actual work to get values and store them in banks.
  • notice the "push_back" has to follow the same order where the variables are defined in banks and the way of push_back double or int type variables are different.

• To add new hitprocess
  • add new_hitprocess.cc and new_hitprocess.h in "hitprocess/solid/"
  • edit SConstruct in the top directory and hitprocess/HitProcess_MapRegister.cc
  • then recompile gemc
  • add the entry for this bank in "solid_hits_def.txt", update bank database with go_hits scipt
  • add bank table under "bankdefs/", run go_bank script to update bank database

hit processing parameter

• "solid_hits_def.txt" has define some parameters relevant to hit processing
  • name -- the same name as hit banks
  • id -- used in output to identify the bank.
  • identifiers -- how to distinguish individual detector component, this determine format used in geometry. eg. "sector stack view strip", refer to geo#sensitivity
  • minEnergy -- minimum energy deposition. Currently not used for real processing, only in visualization. hits with larger, smaller and zero energy deposition are displayed with different colors.
  • TimeWindow -- try to match ADC integration time window or TDC windows. Within the time windows, all hits within a detector component (defined by "identifiers") are combined into one. "0*ns" will have every individual hit as used in "FLUX" and "raw" hit type, but this will slow down processing time a lot.
  • ProdThreshold -- any track with energy smaller than this will not be tracked further, all energy get deposited in current volume. Too large value will give you too few tracks and being unphysical. This was defined in energy unit in Geant4, but Geant4 used a length unit to make material independent. the conversion is within Geant4. Geant4 define this globally with default 1mm, but also can be set for individual volumes. here gemc makes it to set with individual hit process type. (refer to http://geant4.slac.stanford.edu/JLAB2012/Physics3.pdf)
  • MaxStep -- Geant4 calculate step size according to material property. for gas, it can be too large if you need more steps, eg in drift chamber. gemc will take smaller one between this value and Geant4 suggested value.

Note: the text file needs special format, all entry should be separated by a tab, not just some space, you better check the database afterwards to make sure the resulting table is correct!

• Some other parameters defined as run option
  • > Option ENERGY_CUT: Set an energy cut in MeV below which no particle will be tracked further. -1. turns this off.
  • > Option MAX_X_POS: Max X Position in millimeters. Beyond this the track will be killed
  • > Option MAX_Y_POS: Max Y Position in millimeters. Beyond this the track will be killed
  • > Option MAX_Z_POS: Max Z Position in millimeters. Beyond this the track will be killed

hit process result

• The latest hit type definition or bank definition can be viewed from SoLID_GEMC SVN "database_io/banks/bankdefs/"

• pay special attention to detector id format which the detector in geometry definition has to match.

• output files
  • hits are grouped and stored by hit types. for example, generated particles are store in an EVIO bank or a root tree called Tgen, flux of type hits from all kind of detectors are stored in an EVIO bank or a root tree called Tflux.
  • For each event, an incremental event number will be recorded into each bank/tree, then hits corresponding to this event is linked by a pointer.

hit process list

To use "solid" hit process list, include option "-HIT_PROCESS_LIST=solid" which will replace the default option "clas12"

Current solid hit process list include two type "flux" and "raw" they are directly borrowed from clas12.

hit color

red: hit for which the first step Edep is above threshold

blue: hit for which the first step Edep is below threshold

green: hit for which the first step Edep zero

FLUX bank and SoLID detector ID

Flux is often used to record every single hit in a detector. It's definition is here https://jlabsvn.jlab.org/svnroot/solid/solid_gemc/database_io/banks/bankdefs/FLUX.bank

We often use it for simple detector.

Its ID is defined by 7 digits integer like "abcdefg"
a: detector type
   GEM 1, CC 2, EC 3, MRPC 4
b: detector assembly 
   GEM 1 - 6 layer, LGCC 1, HGCC 2, FAEC 1, LAEC 2, FAMRPC 1, LAMRPC 2
c: sub detector
   GEM not used, CC 0 PMT 1 front, MRPC 0 inside 1 front, EC 1 front 2 middle 3 inner 4 rear
d,e,f,g: not used for now
for example, 3110000 is for forward angle EC front plane
see code example here https://jlabsvn.jlab.org/svnroot/solid/solid_gemc/analysistool/background