Project

General

Profile

Actions

Database Parameters » History » Revision 48

« Previous | Revision 48/56 (diff) | Next »
Sean Jeffas, 06/29/2023 02:37 PM


Database Parameters

Naming Convention

All variables follow a naming convention based on a hierarchy of detectors. A period (.) will separate the hierarchy in the variables name. Therefore a name would look like detector.subdetector.subsubdetector.variable. For example one such variable is named bb.gem.modules. This means we are looking at the bb detector and the gem detector in BB and the modules variable.

GEM DB Variables

All gem variables will have the prefix gem. There are GEMs on both sides of the SBS program so the full prefix may be bb.gem or sbs.gem depending on what you want. The GEM modules are listed iteratively as m0, m1, m2, etc. Therefore the DB parameters that are specific to modules will also follow this labeling. To simplify things here we will list DB parameters with m# to denote that this parameter is set for each module.

  • modules - Defines the number of individual GEM modules in the entire tracking stack. List them in the form "m0 m1 m2 . . . mn"
  • m#.layer - Assign layer(tracking plane) number for each and every GEM module (m#). Just like with module numbers, layer numbers start from 0 and goes up until #layers-1. m0 should be assigned 0.
  • m#.position - Position of the center of the module relative to the first module in the stack (m0) in meters. The coordinate system used is +x - vertical down, +y - beam left direction, and +z - downstream/direction of particle motion.
  • m#.angle - Angle of the module with respect to the m0.
  • m#.size - Dimensions of the the module in meters. Uses the same coordinates as the bb.gem.m#.position parameter.
  • m#.apvmap - APV channel to r/o board mapping is different for different types of GEM modules. Use 0 = INFN, 1 = UVA X/Y, 2 = UVA U/V.
  • pedestalmode - Set to 1 if the data is taken in pedestal mode and to 0 if online common-mode and zero suppression was enabled. (Usually does not need to worry and gets overridden by SBS-offline after looking at the state of the data?)
  • All the common mode parameters ...
  • m#.modulegain -
  • m#.ugain -
  • m#.vgain -
  • m#.uangle - Angle of the u strips w.r.t +x direction. Use 150.0 for UVA U/V, 0.0 for UVA X/Y, and 180.0 for INFN X/Y.
  • m#.vangle - Angle of the v strips w.r.t +x direction. This parameter takes care of the layer flipping!. For a case where the readout-board faces the incoming particles (particles first pass through r/o and exits from the gas-window side), use -150.0 for UVA U/V, -90.0 for UVA X/Y, and -90.0 for INFN X/Y. Reverse the sign to account for the case of particles hitting gas-window first.
  • m#.uoffset - u strip offset (from the module center? need to confirm). Put 0.0108 for UVA U/V and 0.0 for UVA X/Y and INFN X/Y.
  • m#.voffset - v strip offset (from the module center? need to confirm). Put 0.0108 for UVA U/V and 0.0 for UVA X/Y and INFN X/Y.
  • m#.nstripsu - Number of u strips in the GEM module.
  • m#.nstripsv - Number of v strips in the GEM module.
  • upitch - The pitch between the consecutive strips for the u strips in meters. Always 400 micrometers (0.0004) in all of our GEM r/o boards.
  • vpitch - The pitch between the consecutive strips for the v strips in meters. Always 400 micrometers (0.0004) in all of our GEM r/o boards.
  • m#.chanmap - The channel map that is used for data decoding. Has the entries: "crate slot fiber/mpd gemid adc_ch i2c pos invert axis" for each and every APV card connected to the GEM module. This information in conjunction with the parameters defined above uniquely maps all the ADC channels (corresponding to each and every r/o channel in the GEMs) in the raw data to the correct location in 3D physical space.
  • m#.maxstrip_t0 - Mean time where good strips are expected. This is only applied to the maximum strip.
  • m#.maxstrip_tcut - Cut around mean time (above) where good strip times are expected. i.e. good strips will have a time that is within t0 ± tcut. This is only applied to the maximum strip.
  • addstrip_tcut - When forming clusters all strips in the cluster must have a time difference between them and the max strip that is less than this value.
  • addstrip_ccor cut - ADC correlation between strips and the max strips in a cluster must be greater than this number.
  • m#.threshold_sample - Maximum ADC time sample for a strip must be above this threshold.
  • m#.threshold_stripsum - Strip time sample ADC sum must be above this threshold.
  • m#.threshold_clustersum - ADC sum of all strip sums in a cluster must be above this threshold.
  • m#.ugain - Gain of each APV card on the U axis of this module.
  • m#.vgain - Gain of each APV card on the V axis of this module.
  • bb.frontconstraint_x0 - Calorimeter front constraint mean x position.
  • bb.frontconstraint_y0 - Calorimeter front constraint mean y position.
  • bb.backconstraint_x0 - Calorimeter back constraint mean x position.
  • bb.backconstraint_y0 - Calorimeter back constraint mean y position.
  • bb.frontconstraintwidth_x - Calorimeter front constraint x width.
  • bb.frontconstraintwidth_y - Calorimeter front constraint y width.
  • bb.backconstraintwidth_x - Calorimeter back constraint x width.
  • bb.backconstraintwidth_x - Calorimeter back constraint y width.

Calorimeter DB Variables

All variables that follow appear in the database files $SBS_REPLAY/DB/db_sbs.hcal.dat (HCal), $SBS_REPLAY/DB/db_bb.ps.dat (BBCal preshower), $SBS_REPLAY/DB/db_bb.sh.dat (BBCal shower), and $SBS_REPLAY/DB/db_bb.ts.dat (BBCal total shower). For the purposes of this list, only active variables (as of 6.22.23) are included. It is worthy to mention that many of the following variables will not appear in all of the above database files either owing to adequate default values or hardware differences rendering the variable obsolete.

Note the following prepends:
  • HCal: sbs.hcal.
  • BBCal Preshower: bb.ps.
  • BBCal Shower: bb.sh.
  • BBCal Total Shower: bb.ts.
The variable appends and definitions follow:
  • detmap - ADC map. Logic maps channels to slots and slots to crates as follows: crate slot start_channel end_channel ref_channel(0:HCal cosmic, 2:Beam)
  • ledmap -
  • start_chanmap -
  • chanmap -
  • position -
  • size -
  • nrows -
  • ncols -
  • xyz -
  • dxdydz -
  • ypos -
  • xpos -
  • emin -
  • tmax -
  • tdc.GoodTimeCut -
  • tdc.offset -
  • tdc.calib -
  • tdc.tw -
  • adc.conv -
  • adc.thres -
  • adc.NpedBin -
  • adc.NSB -
  • adc.NSA -
  • adc.FixThresBin -
  • adc.timeoffset -
  • adc.gain -
  • adc.emin_clSeed -
  • ncols -
  • ncols -

Timing Hodoscope DB Variables

There are 3 database files for the hodoscope. Each is listed and the variables within have the associated prepend:
db_bb.hodo.dat: bb.hodo.
  • nchan
  • is_mc
  • detmap
  • nbars
  • nrows
  • ncols
  • position
  • xyz
  • dxdydz
  • size
  • angle
  • hit_acceptance
  • speed_of_light
  • attenuation
  • bar_geom
  • ref_ch_res
  • left_calib
  • left_gain
  • left_toff
  • left_walkcor
  • left_walkexp
  • left_pedestal
  • right_calib
  • right_gain
  • right_toff
  • right_walkcor
  • right_walkexp
  • right_pedestal
  • tdc.offset
  • tdc.cal
db_bb.hodotdc.dat: bb.hodotdc.
  • detmap
  • chamap
  • position
  • ypos
  • size
  • ncols
  • nrows
  • xyz
  • dxdydz
  • tdcwindowmin
  • tdcwindowmax
  • tdctotmin
  • tdctotmax
  • horizposbarcut
  • timeref
  • timebarcut
  • maxclussize
  • maxyposdiff_clus
  • maxtimediff_clus
  • trackmatchcutX
  • reftdc.GoodTimeCut
  • reftdc.calib
  • reftdc.offset
  • tdc.GoodTimeCut
  • tdc.calib
  • tdc.offset
  • tdcbaroffset
  • timewalk0map
  • timewalk1map
  • vscint
  • tdiffoffset
db_bb.hodoadc.dat: bb.hodoadc.
  • detmap
  • chanmap
  • position
  • ypos
  • size
  • ncols
  • nrows
  • xyz
  • dxdydz
  • adcbaroffset
  • adc.conv
  • adc.thres
  • adc.NPedBin
  • adc.NSB
  • adc.NSA
  • adc.FixThresBin
  • adc.gain
  • adc.pedestal
  • timewalk0map
  • timewalk1map

Updated by Sean Jeffas over 1 year ago · 48 revisions