GtReceiver + GEBSort: Difference between revisions
Line 58: | Line 58: | ||
= GEBMerge = | = GEBMerge = | ||
The GEBMerge is simply merge all raw data file into a signal file. | |||
The detail?? | |||
The control parameters is in working/GEBMerge.chat | |||
$cat GEBMerge.chat | |||
# | |||
# chatfile for GEBMerge | |||
# | |||
echo | |||
#--------------------------------------- | |||
# max coincidence events to create, listing etc | |||
maxNoEvents 2000000000 | |||
TSlistelen 50 1 20 | |||
# | | +-- last bigbuf | |||
# | +-- first bigbuf | |||
# +-- max TS to write per file | |||
nprint 1 | |||
#--------------------------------------- | |||
# output chunk size | |||
chunksiz 2000000000 | |||
#--------------------------------------- | |||
# bigbuf size and wosize | |||
# +--- big size makes program slow; | |||
# but it may be necessary sometimes | |||
bigbufsize 450 | |||
wosize 100 | |||
# | | |||
# +--- in percent of bigbufsize | |||
# written out per buffer | |||
#--------------------------------------- | |||
# how often should we write | |||
# statistics to output | |||
reportinterval 100000 | |||
#--------------------------------------- | |||
# TS jump recovery trigger limits | |||
# (if timestamps jumps outside these | |||
# limits GTMerge will read forward to | |||
# try and recover, 0.1 to 1 sec seems to works) | |||
# 100000000 == 1 sec | |||
# 100000 == 1 ms | |||
# 100 == 1 us | |||
# 1 == 10 ns | |||
dts_min -10000000000 | |||
dts_max 10000000000 | |||
dtsfabort 50 | |||
dtsbabort 50 | |||
# | | |||
# +----- abort recovery and accept TS | |||
# after this many tries in a row | |||
#--------------------------------------- | |||
= EventBuilder (old name : GEBSort) = | = EventBuilder (old name : GEBSort) = |
Latest revision as of 19:15, January 21, 2021
Introduction
To get the data from the digitizer, we need the program "gtReceiver".
To decode the raw data, we need GEBSort.
The version of the firmware of the digitizer, the gtReceiver, and the GEBSort have to be matched to properly extract the data.
gtReceiver
gtReceiver is a C program that connect the IOC and retrieving the data from VME.
in HELIOS DAQ, the folder ~/gtReceiver_digios stored the source code.
The source code should be working fine. (tested for music daq 2020-11-19).
There is server port 9001. should be working fine.
The gtReceover will save data at the location it being called. In the star_run.sh, the path is set to the data folder.
The gtReceiver is set and can be called anywhere.
the argument of the gtReceiver is
gtReceiver [IP] [filename] [max_file_size_in_byte] [data_type] IP = IP for the IOC, it already bookmarked in /etc/hosts, nickname like ioc1, ioc2, ioc3, ioc4 can be used. data_type must be 14 for helios data. it is related to the EventBuilder
The data saved by the gtReceiver will be stored in many files according to the VME. for example:
h078_14C14N_run_046.gtd01_000_0101 h078_14C14N_run_046.gtd01_000_0102 h078_14C14N_run_046.gtd02_000_0105 h078_14C14N_run_046.gtd02_000_0106 h078_14C14N_run_046.gtd02_000_0107 h078_14C14N_run_046.gtd03_000_0109 h078_14C14N_run_046.gtd03_000_0110 h078_14C14N_run_046.gtd03_000_0111 h078_14C14N_run_046.gtd04_000_0113 h078_14C14N_run_046.gtd04_000_0114 h078_14C14N_run_046.gtd04_000_0115
The 2 digits after gtd are the VME ID. The last 2 digits are the global digitizer ID. for example,
h078_14C14N_run_046.gtd03_000_0109
means the data is from VME-3, digitizer-9. since there are 8 digitizers for VME-1 and VEM-2, the digitizer-9 is the 1st digitizer of VME-3.
Sometimes, when the data is more than 2GB (max_file_size_in_byte set in gtReceiver), a new file will be opened, the file name will be
h078_14C14N_run_046.gtd03_000_0109 h078_14C14N_run_046.gtd03_001_0109
GEBMerge
The GEBMerge is simply merge all raw data file into a signal file.
The detail??
The control parameters is in working/GEBMerge.chat
$cat GEBMerge.chat # # chatfile for GEBMerge # echo #--------------------------------------- # max coincidence events to create, listing etc maxNoEvents 2000000000 TSlistelen 50 1 20 # | | +-- last bigbuf # | +-- first bigbuf # +-- max TS to write per file nprint 1 #--------------------------------------- # output chunk size chunksiz 2000000000 #--------------------------------------- # bigbuf size and wosize # +--- big size makes program slow; # but it may be necessary sometimes bigbufsize 450 wosize 100 # | # +--- in percent of bigbufsize # written out per buffer #--------------------------------------- # how often should we write # statistics to output reportinterval 100000 #--------------------------------------- # TS jump recovery trigger limits # (if timestamps jumps outside these # limits GTMerge will read forward to # try and recover, 0.1 to 1 sec seems to works) # 100000000 == 1 sec # 100000 == 1 ms # 100 == 1 us # 1 == 10 ns dts_min -10000000000 dts_max 10000000000 dtsfabort 50 dtsbabort 50 # | # +----- abort recovery and accept TS # after this many tries in a row #---------------------------------------
EventBuilder (old name : GEBSort)
The GEBSort is used for gammasphere, it build events and analysis data, and it split out histogram only.
The EventBuilder is a simplified code from GEBSort. It only build events, and split out root tree.
There are two versions: EventBuilder and EventBuilder_trace
The control parameters for them is the working/GEBSort.chat
$cat GEBSort.chat # NOTE: both the input (geb or file) and # the output (rootfile or mapfile) # are now specified on the command line of GEBSort # all other parameters are specified in this chat file ;DumpEvery 5 #------------------------------------------- # basic sort parameters # number of event in a block nevents 1000000000 # number of event in a block to be printed out printevents 1 # number of event to be written in Log modwrite 100000 # timestamp to be written in Log tsnumwrites 100000 # event build windows timewin 1000 #------------------------------------------- exit
The most important parameter is the timewin. It defines the time-window for an event: whenever data is clustered in the length of the time-window, it is an event.