Brahms offers the user the possibility to store the GEANT hits in a file and to read them back at a later time into the reconstruction program. This saves significant amounts of CPU time if e.g. different reconstruction algorithms should be tested or compared.
The hits are written into a binary stream with on-the-fly compression. A number of simple interface routines are provided to facilitate the writing and reading from the files.
As of Brahms version 306 no knowledge about the length of individual records is needed any more. The interface routines deduce this from the file and read in the appropriate number of bytes automatically. As a consequence the internal format of the hit files has changed between version 305 and 306. While Brahms 306 is backwards compatible and can read old-style files, only new styles ones can be written.
The structure of the file is as follows:
_______________________________________________________________________
SOF => Start of file marker 16 bytes
(1) = 'S'
(2) = 'O'
(3) = 'F'
(4) = number of words in the extended header
_______________________________________________________________________
extended header #(4)*4 bytes- 16 bytes
(1) - (20) code (see Brahms) for subdetector configuration of
the particular run
(21) number of events skipped when doing the simulation
(22) IO version number
(23) code number to identify that version numbers
(23) - #(4) not used
_______________________________________________________________________
MC information: a copy of the kinfile record
(1) number of HEP-evt records
(1)* 15 words per record
------------------------------------------------------------------------
SOR => Start of Run marker 12 bytes
________________________________________________________________________
| Run header 40 bytes
|
| (1) = run number
| (2) = event number
| (3-10) = not used
|_______________________________________________________________________
for each detector stored and for each event:
________________________________________________________________
| Detector header 12 bytes
| (1) = detector ID
| (2) = number of detector blocks
| (3-10)= not used
|_______________________________________________________________
for each detector block
________________________________________________________
| detector block header 40 bytes
| (1) = detector ID (maybe sub-ID, if implemented)
| (2) = version number
| (3) = # of hits stored
| (4) = # of words / hit stored
|_______________________________________________________
for each hit
________________________________________________
| hit information
| (# of hits) * (# of words) * 4 bytes
|_______________________________________________
| MC track information
| (# of hits) * 4 bytes
|_______________________________________________
| volume information (volume number of the hit)
| (# of hits) * (# of words) * 4 bytes
|_______________________________________________
at the end of each event
________________________________________________________________
| EOB = End of Block 12 bytes
|_______________________________________________________________
at the end of the file
________________________________________________________________________
EOF = End of File Marker
________________________________________________________________________
The information stored for each detector is different from detector and detector and mirrors at the moment the information stored in the GEANT hits common blocks. Typically the first three words are the spatial coordinates of the hit (x,y,z) in carthesian coordinates, followed by (if appropriate) the energy deposited and possibly other information. Please refer to the code to find out the exact details.