Receivers/GEBMerge/GEBsort: Difference between revisions
Tlauritsen (talk | contribs) |
Tlauritsen (talk | contribs) |
||
Line 2: | Line 2: | ||
==gtReceiver4== | ==gtReceiver4== | ||
To take data with the DGS DAQ, you must start a | To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number. | ||
To get the | To get the gtReceiverN receiver do the following | ||
* cd to where you want to compile the | * cd to where you want to compile the gtReceiverN programs | ||
wget http://www.phy.anl.gov/gretina/gtreceiver/tar.tgz | wget http://www.phy.anl.gov/gretina/gtreceiver/tar.tgz | ||
Line 17: | Line 17: | ||
* make | * make | ||
That should generate the gtReceiver4 and gtReceiver5 programs as well as the | That should generate the gtReceiver4 and gtReceiver5 programs as well as the outdated gtReceiver3 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here are some examples on how to run the programs: | ||
gtReceiver4 ioc1 data_run_001.gtd 2000000000 14 | gtReceiver4 ioc1 data_run_001.gtd 2000000000 14 | ||
gtReceiver5 ioc1 data_run_001.gtd 2000000000 14 | gtReceiver5 ioc1 data_run_001.gtd 2000000000 14 | ||
Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 as ID, and put the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4 splits the data stream into a file for each of the digitizers the IOC serves. That makes it easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. | Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 as ID, and put the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines. | ||
The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore. | The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore. |
Revision as of 16:00, July 28, 2014
gtReceiver4
To take data with the DGS DAQ, you must start a gtReceiverN (N=3..5) program for each of the IOCs that are collecting data. This is usually done from a script which starts all the necessary receivers and controls the run number.
To get the gtReceiverN receiver do the following
- cd to where you want to compile the gtReceiverN programs
wget http://www.phy.anl.gov/gretina/gtreceiver/tar.tgz tar -zxvf tar.tgz or svn checkout https://svn.anl.gov/repos/gs_analysis/gtReceiver .
- make clean
- make
That should generate the gtReceiver4 and gtReceiver5 programs as well as the outdated gtReceiver3 program. gtReciver5 should work just like gtReceiver4; but it buffers the digitizer data and sorts the timestamps before writing the data to disk. Thus, with gtReciver5 you should be able to run in 'copy' mode, avoiding using the IOC CPU to do the TS sorting task. Here are some examples on how to run the programs:
gtReceiver4 ioc1 data_run_001.gtd 2000000000 14 gtReceiver5 ioc1 data_run_001.gtd 2000000000 14
Here we are asking gtReceiver4/gtReceiver5 to acquire data from ioc1, use a GEB ID of 14 as ID, and put the data in the file data_run_001.gtd. That will not actually be one file as gtReceiver4/gtReceiver5 splits the data stream into a file for each of the digitizers the IOC serves. That makes it easier to merge and time order the DGS data later. 2000000000 specifies the max size of the files, here keeping them under 2GBytes, so they can be read on all machines.
The gtReceiver4/gtReceiver5 program writes data out in the GRETINA GEBheader/Payload form. This means that the GT GEBMerge and GEBSort programs can be used for DGS data as well as GT data. gtReceiver3 writes data witout GEB headers and should not be used anymore.
GEBMerge
GEBMerge allows you to merge all the files that the instances of the gtReceiver4 created during your run. In addition to merging the data, GEBMerge also orders the merged data based on the timestamps in the GEB header. This merger and time stamp ordering program will work on all kinds of data, as long as the data are in the GT GEB header/Payload format, including data taken with the gtReceiver4 receiver.
You will use the program as
GEBMerge GEBMerge.chat outfile file1 file2 file3 file4 .....
where GEBMerge.chat is the file that contains parameters for the merging, such as the buffer size to use. The merged data will be written to outfile and file1 file2 file3 file4 ..... is the list of files to merge.
GEBMerge is part of the GEBSort package. See the link below for how to get the GEBSort package. gtReceiver4 is specific to DGS; but the GEBSort package can handle many other kinds of data as well. Sometimes you will want to use GEBMerge on GRETINA data as well as the program also time orders the data.
GEBSort
GEBSort is a rather general purpose ROOT sorter, that, in addition to being able to read GRETINA data, also can read DGS data acquired by gtReceiver4. This sorter is documented under the GRETINA wiki pages
[1]