BGO ring at JSI and how to operate it
Flood calibration
Data colletction
Run
vmedaq ~/.vmedaq/bgo_ring.xml
Set coincidence module to OR. Make sure the GATE width is long enough for
peak of the signal to be recorded. Store data into flood directory
Data processing
Command is
bin/decoderBgoFloodNoFPGA
/data0/studen/data/imageRec/studies/setup_ijs_pointSource/processFlood.config
The configuration file looks something like this:
#run with decoderBgoFloodNoFPGA
files=/net/f9pc31/data0/diploma/20161116/flood/Na22_bgoRing_r260_flood_000001
eventsDotOut=/afs/f9.ijs.si/data/lab/studen/data/20161116/flood/out/Na22_bgoRing_r260_flood_run1.out
nPedestal=10000
nPedestalBGO=10000
configFile=/net/f9pc22/data0/studen/data/imageRec/studies/setup_ijs_pointSource/m30.cfg
It contains pointer to the study configuration, stored in m30.cfg. That
file has the following structure:
pga_id=100
nModules=1
type_0=3
setupPath_0=/net/f9pc22/data0/studen/data/imageRec/layout/setup_ijs
studyPath_0=/net/f9pc22/data0/studen/data/imageRec/studies/setup_ijs_pointSource
channels_0=_setupPath_/bgoChM3.in
blocks_0=_setupPath_/m3Block.in
adcs_0=_setupPath_/adc.in
arcs_0=_setupPath_/arcs.in
geo_0=_setupPath_/ijsRing.in
settings_0=_localPath_/settings.in
blockCalib_0=_localPath_/blockCalib_20161116.in
#
nCoinc=1
coinc_0_coincFlag=100
coinc_0_module_0=300
coinc_0_module_1=301
coinc_0_nSel=0
coinc_0_eSel_0_type=energy
coinc_0_eSel_0_module=300
coinc_0_eSel_0_nPar=2
coinc_0_eSel_0_par_0=350
coinc_0_eSel_0_par_1=750
coinc_0_eSel_1_type=energy
coinc_0_eSel_1_module=301
coinc_0_eSel_1_nPar=2
coinc_0_eSel_1_par_0=350
coinc_0_eSel_1_par_1=750
#
fake_trigCh0=0
fake_timeCh0=0
fake_trigCh1=1
fake_timeCh1=0
fake_coinc=100
fake_evtTime=77
fake_trigreg=3
The coinc part lists the possible coincidences (just one), the fake part
provides fake data for FPGA coincidence event.
Configuration is split to two areas - setup - where stable parameters are stored (number of BGO crystals) and - study - where run related parameters (calibration data) are stored.
There is more data hidden in the separate configuration files. For
channels, it stores a map of channels. Each electronic channel connects
the processing position of a channel in the ADC block to the physical
position characterized by block ID and relative position within a block.
Our small setup looks like this:
nCh=8
#for each channel (Y) in module (X) assign
#
# * block from range of blocks
#blockMap_X_ch_Y=0
#
# * relative position of the channel from 0 to 3
#relPosMap_X_ch_Y=0
#
# * ADC module from the set
#adc_X_ch_Y=300//ADC module where it appears
#
# * channel range within the ADC
# adcCh_X_ch_Y=0
#
# * position of the trigger in the trigger register in FPGA
# trigCh_X_ch_Y=4
#
# * assignment to the arc out of the possible arc ids
# arc_X_ch_Y=300
#
#ch0
#
block_0=0
#relPos_0=2
relPos_0=0
adc_0=1024
adcCh_0=11
#
#ch1
#
block_1=0
relPos_1=1
adc_1=1024
adcCh_1=12
#
#ch2
#
block_2=0
relPos_2=3
adc_2=1024
adcCh_2=13
#
#ch3
#
block_3=0
#relPos_3=0
relPos_3=2
adc_3=1024
adcCh_3=14
#
#ch4
#
block_4=1
#relPos_4=0
relPos_4=2
adc_4=1024
adcCh_4=2
#
#ch5
#
block_5=1
relPos_5=3
adc_5=1024
adcCh_5=3
#
#ch6
#
block_6=1
relPos_6=1
adc_6=1024
adcCh_6=4
#
#ch7
#
block_7=1
#relPos_7=2
relPos_7=0
adc_7=1024
adcCh_7=5
More complex geometries need maps with more entries. The blocks are described separately, there we give relative position within an arc (if there is an arc), the trigger channel and arc id.
#
#
# B L O C K S
#
#
nBlocks=2
#
#
# for each block find relative position, trigger channel, arc and mesh
divider
#
#block0
#
active_0=1
relPos_0=0
trigCh_0=0
arc_0=300
#
#block1
#
active_1=1
relPos_1=0
trigCh_1=1
arc_1=301
Calibration data is stored separately - here is a look at our blockCalib
entry:
#
#
# B L O C K S
#
#
nBlocks=2
calibPath=/afs/f9.ijs.si/data/lab/studen/data/20161116/flood/out
#
#
# for each block find relative position, trigger channel, arc and mesh
divider
#
#block0
#
block_0=0
#arc_0=300
mesh_0=mesh_300_20161116.txt
gain_0=bgoUnitGain32.txt
#
#block1
#
block_1=1
#arc_1=301
mesh_1=mesh_301_20161116.txt
gain_1=bgoUnitGain32.txt
Path to the calibration is provided where gain and mesh files are stored which are used in mapping and spectrum scaling. Only blocks that have calibration entries are made active.
ADCs just lists ADC numbers. In our case, we called ours 1024 in vmedaq:
# A D C s
#
nADCs=1
#
# ADC 1024
adcID_0=1024
Arc lists arcs and gives their geometric position, rotation and shifts:
#ARCS
nArcs=2
#
#
#specify id and position/rotation
arcID_0=300
ID_0=300
pos_x_0=0
pos_y_0=0
pos_z_0=0
rot_xx_0=-1
rot_xy_0=0
rot_xz_0=0
rot_yx_0=0
rot_yy_0=-1
rot_yz_0=0
rot_zx_0=0
rot_zy_0=0
rot_zz_0=1
rho_0=260
side_0=0
sideID_0=10
legacyOffset_0=0
legacyBlocks_0=0
mask_0=mask300.txt
efficiency_0=eff300.txt
#
#
arcID_1=301
ID_1=301
pos_x_1=0
pos_y_1=0
pos_z_1=0
rot_xx_1=1
rot_xy_1=0
rot_xz_1=0
rot_yx_1=0
rot_yy_1=1
rot_yz_1=0
rot_zx_1=0
rot_zy_1=0
rot_zz_1=1
rho_1=260
Another parameter is geo, the geometry of the ring, which comes in a
separate file:
#block geometry
nCrystalPerModule_2=32
nModulesPerCircle_2=16
nCrystalPerRowInModule_2=8
crystalSizeY_2=13.35
The final piece of information are the processing settings:
#common processing settings
noise_cut=5
block_effect=1.5
pedestal_sigma_guess=10
The file generated by processing will add to the eventsDotOut variable by
noting number of BGO blocks (B) that were hit. So we normally get:
ll /afs/f9.ijs.si/data/lab/studen/data/20161116/flood/out/
-rw-r--r-- 1 studen f9 2463 Nov 17 12:40 Na22_bgoRing_r260_flood_run1_B0_s0_s0.out
-rw-r--r-- 1 studen f9 81056109 Nov 17 12:40 Na22_bgoRing_r260_flood_run1_B1_s0_s0.out
-rw-r--r-- 1 studen f9 35296553 Nov 17 12:40 Na22_bgoRing_r260_flood_run1_B2_s0_s0.out
Flood analysis
Go to
cd ~/software/build/observer_tools/flood/root_scripts
root
root[].L scripts_generateData.C+
root[] TH2D h2;
root[]
generateData("/afs/f9.ijs.si/data/lab/studen/data/20161116/flood/out/Na22_bgoRing_r260_flood_run1_B1_s0_s0.out",
h2,300,301);
root[] h2.Draw("COLZ")
root[] mesh_optimizer m; gphx gp;
root[] initMesh(m,&h2)
The initMesh is an automatic segmentation routine, which sometimes fails.
The results are best checked by issuing:
root[] h2.Draw("COLZ");
root[] drawCenters(gp,m,kGreen);
If initMesh failed miserably, than it is better to load fits from an old
file, for example:
root[] readCenters(m,"/afs/f9.ijs.si/data/lab/studen/data/20161116/flood/out")
root[] drawCenters(gp,m,kGreen)
More often, just a few of the dots will be misplaced. Then it usually sufficies to move the markers around on the histogram, and then do
root[] setCenters(gp,m)
From centers, mesh is initialized and can be verified by drawing:
root[] makeMesh(m,&h2);
root[] drawMesh(gp,m,kGreen);
If everything looks peachy, just save the mesh to someplace you will find it later on
root[] dumpMesh(m,"/afs/f9.ijs.si/data/lab/studen/data/20161116/flood/out/mesh_301_20161116.txt")
Then you should re-process the flood data with the new mesh.