A variety of DataBases are used in the SciFi project. E.g. during the production of the various detector components (modules, cold-boxes, readout boxes, etc.) information was stored in the so-called Heidelberg Production Database. For the operation of the SciFi online system, a number of additional DataBases are necessary.
The overall design of the SciFi Online DataBase is described in SciFi Online Databases EDMS Doc. 2050116.
The SciFi Online DataBase consists of several tables, that can be grouped in few broad categories:
Table Types
Geographical Tables: containing, for each detector location (e.g. T1L0Q0), the list of all unique identifiers of the various components (e.g. module serial numbers, readout boxes serial numbers, etc.);
PACIFIC Configuration Tables: containing the values of those PACIFIC settings (gain, shaper settings and threshold type) that may be set differently than what specified in the Component Tables;
Run-Parameters Tables: containing the values of those parameters that may be set differently for different run types;
Calibration Tables: containing the values of those parameters that are routinely updated as a result of calibrations procedures (light-injection, timing, etc.)
In a database, entities are uniquely identified by certain attributes called keys. The entities in the various tables of the SciFi Online DataBase use a variety of such keys, like dates, component serial numbers, position in the detector, run type, etc. We assume the reader to be familiar with the meaning of most of these keys.
DB Access
The SciFi Online DataBase is hosted by lhcbonr-s.cern.ch (service name lhcbonr.cern.ch). It is structured as an Oracle schema, a collection of database objects owned by a database user and with the same name as that user, sf_components.
Access to this schema outside the CERN intranet requires setting up tunnelling via lxplus.cern.ch. In order to set up a tunnel to lhcbonr-s.cern.ch (port 10121), you cannot use the CERN functional alias lhcbonr-s.cern.ch but need to discover the -v host names behind it:
$ host lhcbonr-s.cern.ch
lhcbonr-s.cern.ch is an aliasfor db-rac-232.cern.ch.
db-rac-232.cern.ch has address 10.116.96.94
db-rac-232.cern.ch has address 10.116.96.126
$ host 10.116.96.94
94.96.116.10.in-addr.arpa domain name pointer itrac5406-s.cern.ch.
-$ host 10.116.96.126
126.96.116.10.in-addr.arpa domain name pointer itrac5426-s.cern.ch.
According to the results above, one needs to set up tunnels to itrac5406-v.cern.ch:10121 and itrac5426-v.cern.ch:10121 (note that you need to use the hostname-v interfaces); e.g. in putty, you could forward localhost ports 10004 and 10005 as follows:
L 10004 itrac5426-v.cern.ch:10121
L 10005 itrac5406-v.cern.ch:10121
A number of schema's with limited-privileges is created to allow different operations on sf_components via aliases to schema tables.
N.B.
The procedure to access DB's outside the CERN intranet is well documented on the CERN Service Portal.
There it is also described how information about the database service lhcbonr can be obtained by running tnsping
$ export ORACLE_CERN=/eos/project/o/oracle/public
$ oraversion=$($ORACLE_CERN/script/setoraenv.sh -l | grep "^11" | grep "\-\->" | head -1 | cut -f1 -d' ')
$ . $ORACLE_CERN/script/setoraenv.sh -s $oraversion
$ export LD_LIBRARY_PATH=$ORACLE_CERN/linux/$oraversion/lib:$LD_LIBRARY_PATH
$ export TNS_ADMIN=$ORACLE_CERN/admin
$ tnsping lhcbonr
TNS Ping Utility for Linux: Version 11.2.0.4.0 - Production on 24-MAR-2023 11:07:07
Copyright (c) 1997, 2013, Oracle. All rights reserved.
Used parameter files: /eos/project/o/oracle/public/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact ( DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=lhcbonr-s.cern.ch) (PORT=10121)) (LOAD_BALANCE=on) (CONNECT_DATA= (SERVER=DEDICATED) (SERVICE_NAME=LHCBONR.cern.ch)))
OK (10 msec)
Geographical Tables
The Geographical tables contain the list of all hardware installed in each detector position, e.g. T1L0Q0M0, every piece of hardware (module, read-out box etc.) being uniquely identified by the same serial number by which it is identified in the Component Tables.
Further information on these tables should be written by Blake/Snow/Alexey.
This information should include the relational diagram, with the description of how, when and by whom these tables are updated and how updates are tracked.
Component Tables
The tables contain the subset of information from the Heidelberg Production Database that is relevant to the detector operation.
Further information on these tables should be written by Blake/Snow/Alexey.
This information should include the relational diagram, with the description of how, when and by whom these tables are updated and how updates are tracked.
Run Types
The concept of SciFi Run-Types are described elsewhere but, for the sake of clarity, the list of run types is re-summarized here:
SciFi Run Types
BEAM_TI_SCAN;
CHARGE_TH_SCAN;
LIS_TH_SCAN;
VTTXBIAS_SCAN;
FPGA_PRBS_BER_TI_SCAN;
PACIFIC_BER_TI_SCAN;
PHYSICS.
Each type of run in the list above will require different SciFi operational parameters. These SciFi Run-Types have actually been defined in the DAQFEE projects with the main goal of providing a systematic approach to the
generation of DAQFEE recipes. For each one of these SciFi Run-Types a specific table in the SciFi Online Database,
called a Run Parameter Table, will contain all DAQFEE settings specific to that run type.
Figure 1. Entity Relationship Diagram (ERD).
Run Parameter Tables
Some parameters of the SciFi FE Electronics may take different settings for different run types. The values of these parameters that are intended to be used for the WinCC recipes, are contained in the following tables:
Run Parameter Tables
RUN_PARAMETERS_MB_DATAGBT;
RUN_PARAMETERS_MB;
RUN_PARAMETERS_LIS;
RUN_PARAMETERS_CB;
RUN_PARAMETERS_ASIC;
RUN_PARAMETERS_ASIC_LCLVTH.
Each table is indexed by Board-Id (i.e. the unique identifiers assigned to each board in the Heidelberg Production Database during production) and by Run-Type; each table thus contains Nrun-types × Nboards entries.
N.B.
Run-parameter tables thus contain only the latest choice of the parameters and no history of how they were modified in the course of time. Historical searches or systematic studies can only be carried out through a dedicated study of the XML files and
of the upload-tool log file.
Filling the Run Parameter Tables
The content of the Run Parameter Tables is set on the base of the following XML files, stored in /group/sf/etc/OnlineDB/RunParameters:
PHYSICS.xml;
BEAM_TI_SCAN.xml;
FPGA_PRBS_BER_TI_SCAN.xml;
PACIFIC_BER_TI_SCAN.xml;
CHARGE_TH_SCAN.xml;
LIS_TH_SCAN.xml;
VTTXBIAS_SCAN.xml.
Each <Entry>...</Entry> in the XML files define a block listing the run-parameters of a given piece of hardware (tagged by <ProdDBId>...</ProdDBId>) that have to be stored in a given run-parameter table, tagged by <Table>...</Table>.
The XML file may contain any combination of hardware, meaning e.g. that is not mandatory to have entries for each type of hardware (MB, MB_DATAGBT, LIS, CB, ASIC, ASIC_LCLVTH) and for each type is not mandatory to have the complete list (e.g. of all that was ever produced or of all hardware actually used in the detector): this flexibility in the XML structure allows the user of the Import Tool to obtain the desired result, be that the complete filling of all or only some tables, or the modification of the run-parameters of only a single piece of hardware, etc. Consequently, it is
the user who is responsible for the actual effect on the data-base of the content of the XML files he feeds to the Import Tool.
The only constraint on the XML structure is that, for each actual parameter block <RunParameters>...</RunParameters>, the list of all foreseen parameters must be complete. E.g. in a RUN_PARAMETERS_MB entry is not possible to define only the delays MASTER_CLKDEL{0-7} and leave undefined VTRX_IBIAS and VTRX_IMOD (This rule is relaxed in the case of XML files used to update calibration tables to allow the update of individual parameters while leaving the others unchanged).
The first version of these XML files was created by the bash script genxml.sh on the base of template XML files and of serial-numbers CSV files located in /group/sf/etc/OnlineDB/RunParameters/RunParameters-Reset (see README.txt for instructions).
N.B.
Values for MASTER_CLKDEL{0-7} are also set in the TIME_CALIB_MB table (as a result of a BEAM_TI_SCAN)! This duplication of values in two DB tables is precautionary, as at the moment of this write-up is unclear whether run-type dependent values of MASTER_CLKDEL{0-7} are necessary. The present implementation envisages the use of the values in the Run-Parameter Tables for LIS_TH_SCAN and of those in the TIME_CALIB_MB table for all other run types.
<Entry><Table>RUN_PARAMETERS_LIS</Table><ProdDBId>ELSXXXXX</ProdDBId><ProdDBFAMId desc="Valid only for this FAM">FAMXXXXX</ProdDBFAMId><RunParameters><DISABLE_LIS desc="">...</DISABLE_LIS><GBLD0_IMOD desc="">...</GBLD0_IMOD><GBLD0_IBIAS desc="">...</GBLD0_IBIAS><GBLD0_MATPOS desc="">0x2</GBLD0_MATPOS><GBLD1_IMOD desc="">...</GBLD1_IMOD><GBLD1_IBIAS desc="">...</GBLD1_IBIAS><GBLD1_MATPOS desc="">0x0</GBLD1_MATPOS></RunParameters></Entry>
N.B.
This RUN_PARAMETERS_LIS table has a few points that require attention:
Strictly speaking, the only run-type-dependent LIS setting is DISABLE_LIS, which is enabled for LIS_TH_SCAN and disabled for all other types of runs.
The values of GBLD{0,1}_IMOD and GBLD{0,1}_IBIAS are calibration values that have been determined during module assembly in the gray room and stored in the Heidelberg Production Database. However, some of these values have been updated during commissioning in the assembly hall, and in principle it may be necessary to update them again in the future. Storing them in this run-parameter table is thus a trick that provides a mechanism to change them on the fly; correspondingly, the Recipe Creator must only use the values of GBLD{0,1}_IMOD and GBLD{0,1}_IBIAS from RUN_PARAMETERS_LIS (and not those from the Heidelberg Production Database). With this policy in place, the user who fills in the RUN_PARAMETERS_LIS table (as of now Snow) takes the responsibility of setting the values in the recipe. I think that this mechanism should be revised in the future: if these values are updated routinely, then they should be moved to a dedicated calibration table.
the key of each entry in this table: using ELSXXXXX is in principle not sufficient, because the settings are valid only for a given coupling of the LIS mezzanine to certain fiber mats; FAMXXXXX is added to this table, to provide a handle for a possible consistency check (during recipe creation).
The values of GBLD{0,1}_MATPOS, previously stored in this table, are commodity values, that are only used as information in a DAQFEE expert panel. They have therefore been removed from this table. Their master source is the Heidelberg Production Database. Eg for usage of expert panels in DAQFEE they could be stored in a stand-alone file, that will then need to be kept up to date manually.
<Entry><Table>RUN_PARAMETERS_ASIC</Table><ProdDBId>EPAXXXXX</ProdDBId><RunParameters><DBG_CIN desc="">...</DBG_CIN><DBG_CH desc="">...</DBG_CH><DBG_EN_IN desc="">...</DBG_EN_IN><COMMONVTHS desc="">...</COMMONVTHS><THRESHOLD_SELECT_COMMONVTH desc="R, L or Q">...</THRESHOLD_SELECT_COMMONVTH><EXT_SERIAL_IN desc="">...</EXT_SERIAL_IN></RunParameters></Entry>
N.B.
The settings of the PACIFIC DBG registers necessary to enable the charge injectors for a CHARGE_TH_SCAN
are the following:
DBG_CIN = 0x1
DBG_CH = 0xFFFF FFFF FFFF FFFF
DBG_EN_IN = 0x1
Each COMMONVTHS XML tag actually contains the values of all three common thresholds Vth1, Vth2, Vth3, encoded as
Vth = [(VTH1<<4) & 0xFF0000] | [(VTH2<<2) & 0xFF00] | [(VTH3<<0) & 0xFF], such that e.g. 0x0077FF will mean Vth1 = 0, Vth2 = 119, Vth3 = 255.
For each ASIC, one can choose between the automatically-calibrated common thresholds stored in the
TH_CALIB_ASIC table or the custom common threshold values
set in the RUN_PARAMETERS_ASIC table,
using the THRESHOLD_SELECT_COMMONVTH character
(see Threshold Selection in Recipe Creation).
The PACIFIC ASIC implements so-called "Eight channel block control registers". Each ASIC has eight such blocks,
specified by the BLOCK XML tag. Each block contains 24 8-bits local threshold values, three values per channel Vth1, Vth2, Vth3,
specified by the LOCALVTH_CHx XML tag.
Each LOCALVTH_CHx XML tag actually contains the values of all three local thresholds Vth1, Vth2, Vth3, encoded as
Vth = [(VTH1<<4) & 0xFF0000] | [(VTH2<<2) & 0xFF00] | [(VTH3<<0) & 0xFF], such that e.g. 0x0077FF will mean Vth1 = 0, Vth2 = 119, Vth3 = 255.
For each channel, one can choose whether to use the three common threshold values stored in the
RUN_PARAMETERS_ASIC table (specified by the COMMONVTHS XML tag)
or the three local threshold values stored in this table. The selection is made through the threshold selection8-bits registers, specified by the COM_LCL XML tag (one bit per channel, 0=common, 1=local).
Values in the run-parameter XML files can be uploaded to the SciFi Online DataBase using a dedicated tool. The detailed documentation concerning this tool can be found on Karol's Tools twiki page, directly in the Run-Parameter Import Tool Manual.
Please note that:
no history of parameter changes is kept: every time the Import Tool encounters a given
combination of board-id and run-type in the XML files,
previous entries for that combination are over-written;
for combinations of board-id and run-type existing in the run-parameter tables but for which no update value is found in the
XML files, the existing values are kept;
all combinations of valid run-types and of valid board-id's (those actually existing) need to be
initialized in the tables before the tables can be used by the Recipe Creator;
A dedicated table, the RUN_PARAMETER_IMPORT table, contains the time-stamps of all the sessions in which the
Import Tool has modified any run-parameter table.
The combined effect of the choices listed above can give rise to many options; although not all of them may really be meaningful and/or relevant, our software interface tries to be as flexible as possible to allow virtually all possibilities.
The actual choices are determined by the values of the three parameters COM_LCL (0=common and 1=local), THRESHOLD_SELECT_COMMONVTH,
THRESHOLD_SELECT_LOCALVTH (L: use values from LIS calibration in
TH_CALIB_ASIC,
TH_CALIB_ASIC_LCLVTH tables;
Q: use values from charge injection in
TH_CALIB_ASIC,
TH_CALIB_ASIC_LCLVTH tables;
R: use custom values in
RUN_PARAMETERS_ASIC, RUN_PARAMETERS_ASIC_LCLVTH tables).
Figure 2. Threshold choice in recipe creation.
Under normal circumstances, the values in the TH_CALIB_ASIC and TH_CALIB_ASIC_LCLVTH tables are used for PHYSICS and BEAM_TI_SCAN runs and those in the RUN_PARAMETERS_ASIC, RUN_PARAMETERS_ASIC_LCLVTH tables
are used for all other run types. However, through the combined usage of COM_LCL, THRESHOLD_SELECT_COMMONVTH and THRESHOLD_SELECT_LOCALVTH, any custom behavior can be obtained. We list below a few examples to clarify how this could be done.
<Entry><Table>RUN_PARAMETERS_ASIC</Table><ProdDBId>EPA00036</ProdDBId><RunParameters><DBG_CIN desc="">...</DBG_CIN><DBG_CH desc="">...</DBG_CH><DBG_EN_IN desc="">...</DBG_EN_IN><COMMONVTHS desc="">...</COMMONVTHS><THRESHOLD_SELECT_COMMONVTH desc="R, L or Q">L</THRESHOLD_SELECT_COMMONVTH><EXT_SERIAL_IN desc="">...</EXT_SERIAL_IN></RunParameters></Entry><Entry><Table>RUN_PAR_ASIC_LCLVTH</Table><ProdDBId>EPA00036</ProdDBId><RunParameters><ThresholdData><BLOCK>0</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>...</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>...</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0x00</COM_LCL></ThresholdData>
...
<ThresholdData><BLOCK>7</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>...</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>...</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0x00</COM_LCL></ThresholdData></RunParameters></Entry>
Example PHYSICS run with custom settings
Under normal circumstances, in PHYSICS and BEAM_TI_SCAN runs,
local thresholds from the TH_CALIB_ASIC_LCLVTH table will
be used. Suppose that, instead, you want to set one specific channel of one specific ASIC,
say channel 36 (configuration register block 4, channel 4) of EPA00036,
to use custom threshold values Vth1=0x11, Vth2=0x22, Vth3==0x33.
To obtain this, the RUN_PARAMETERS_ASIC, RUN_PARAMETERS_ASIC_LCLVTH tables will have to be
filled as follows:
<Entry><Table>RUN_PARAMETERS_ASIC</Table><ProdDBId>EPA00036</ProdDBId><RunParameters><DBG_CIN desc="">...</DBG_CIN><DBG_CH desc="">...</DBG_CH><DBG_EN_IN desc="">...</DBG_EN_IN><COMMONVTHS desc="">...</COMMONVTHS><THRESHOLD_SELECT_COMMONVTH desc="R, L or Q">...</THRESHOLD_SELECT_COMMONVTH><EXT_SERIAL_IN desc="">...</EXT_SERIAL_IN></RunParameters></Entry><Entry><Table>RUN_PAR_ASIC_LCLVTH</Table><ProdDBId>EPA00036</ProdDBId><RunParameters><ThresholdData><BLOCK>0</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>...</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>LLLLLLLL</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0xFF</COM_LCL></ThresholdData>
...
<ThresholdData><BLOCK>4</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>0x112233</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>LLLRLLLL</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0xFF</COM_LCL></ThresholdData>
...
<ThresholdData><BLOCK>7</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>...</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>LLLLLLLL</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0xFF</COM_LCL></ThresholdData></RunParameters></Entry>
<Entry><Table>RUN_PARAMETERS_ASIC</Table><ProdDBId>EPAXXXXX</ProdDBId><RunParameters><DBG_CIN desc="">...</DBG_CIN><DBG_CH desc="">...</DBG_CH><DBG_EN_IN desc="">...</DBG_EN_IN><COMMONVTHS desc="">...</COMMONVTHS><THRESHOLD_SELECT_COMMONVTH desc="R, L or Q">R</THRESHOLD_SELECT_COMMONVTH><EXT_SERIAL_IN desc="">...</EXT_SERIAL_IN></RunParameters></Entry><Entry><Table>RUN_PAR_ASIC_LCLVTH</Table><ProdDBId>EPAXXXXX</ProdDBId><RunParameters><ThresholdData><BLOCK>0</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>...</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>...</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0x00</COM_LCL></ThresholdData>
...
<ThresholdData><BLOCK>7</BLOCK><LOCALVTH_CH0>...</LOCALVTH_CH0><LOCALVTH_CH1>...</LOCALVTH_CH1><LOCALVTH_CH2>...</LOCALVTH_CH2><LOCALVTH_CH3>...</LOCALVTH_CH3><LOCALVTH_CH4>...</LOCALVTH_CH4><LOCALVTH_CH5>...</LOCALVTH_CH5><LOCALVTH_CH6>...</LOCALVTH_CH6><LOCALVTH_CH7>...</LOCALVTH_CH7><THRESHOLD_SELECT_LOCALVTH>...</THRESHOLD_SELECT_LOCALVTH><COM_LCL>0x00</COM_LCL></ThresholdData></RunParameters></Entry>
PACIFIC Configuration Table
It may be desirable (e.g. for test or debugging) to assign to some PACIFIC settings values different than those specified in the
Heidelberg Production Database. The settings for which this is likely to happen are the gain and the shaper settings. These settings are therefore stored in a special table called PACIFIC Configuration Table. In the recipe creation,
the settings in this table are given higher priority than those from the Heidelberg Production Database. In the present implementation,
we only foresee the option to make a global choice of these parameters across the whole detector (as opposed
to as many tuples as PACIFIC ASICs).
PACIFIC Configuration Parameters
ASIC gain PACIFIC input stage gain setting: 0,1,2,3 written in the 2-bit Gain configuration register, with 0 corresponding to the smallest and 3 to the highest gain;
ASIC shaper setting PACIFIC pole zero resistors/capacitors shaper settings (Rlad_PZ1, Cap_PZ1, CapF_PZ1, Rlad_PZ2, Cap_PZ2, CapF_PZ2).
PACIFIC_CONF
PACIFIC_CONF: Key = Configuration Name, as many entries as possible configurations
A simple user interface is foreseen, in the form of a text file
containing a header and on each row a configuration name, and the values of all PACIFIC Configuration Parameters.
Calibration-Run Table
Some parameters of the SciFi FE Electronics will continuously be updated (calibrated). Several automatic calibration procedures are in place to ensure that at any given time the best values of PACIFIC thresholds, clock delays etc. are used during data taking. Every time that such a calibration run is taken (all types of calibration runs are listed here), a WinCC manager records real-time information in a dedicated CALIB_RUN table, that serves as log of the conditions at which the calibration run was taken.
Calibration Run Conditions
By “run conditions” we mean all those values on which the results of the calibration may depend. Some of these conditions are real-time values, namely the date and time at which the run was taken and the SiPM over-voltage and temperature read back from the detector at the moment of the run; others are chosen by the user who sets up the calibration run in SFECS, namely the Recipe (the recipe choice implies also the choice of the SciFi Run Type).
The results of the calibration might in principle depend on all hardware settings contained in the recipe; if needed, these can be retrieved from the FSM Configuration DB. Some settings (PACIFIC configuration and PACIFIC thresholds) are of special importance and they (or rather references to them) are permanently stored in the so-called Recipe-Creation Table, from which they can be directly retrieved without the need to access the FSM Configuration DB.
CALIB_RUN
CALIB_RUN: Key = Run Number, as many entries as calibration runs taken
The best values of the calibration parameters (determined from the automatic calibration procedures) that are to be used for the WinCC recipes are contained in the tables listed below.
Calibration Tables containing the best values of the constants to optimize data digitization and transmission (obtained from the FEE Time and the FEE Optical-Transmission Calibration)
TIME_CALIB_MB;
TIME_CALIB_MB_DATAGBT;
TIME_CALIB_CB.
Calibration Tables containing the best values of the PACIFIC comparator thresholds (obtained from the FEE Threshold Calibration )
TH_CALIB_MB;
TH_CALIB_MB_DATAGBT;
TH_CALIB_CB;
TH_CALIB_ASIC;
TH_CALIB_ASIC_LCLVTH (currently calledACALIB).
The recipe-creator software will retrieve the calibration parameters from the tables above to create new FSM recipes. At the end of the present section, is presented an overview of the full cycle through which a calibration run is taken, its results analyzed and stored in the calibration tables, then used to create new recipes and finally applied to the detector hardware.
Calibration Table Structure
TIME_CALIB_MB
TIME_CALIB_MB: Key = EMBXXXXX, as many entries as EMB's
Please note that, although the CLKDEL5,CLKDEL6 values of GBT_{0, 1, 2, 4, 5, 6, 7} are irrelevant (only GBT_3/CLKDEL5 and GBT_3/CLKDEL6 are actually used to define the LIS pulse start and stop), the TH_CALIB_MB_DATAGBT table will contain them as well for completeness.
TH_CALIB_CB
TH_CALIB_CB: Key = ECBXXXXX, as many entries as ECB's
How calibration runs are taken and analyzed to obtain the best values of the calibration parameters is described in detail in the Scan Runs Twiki Page. In this section we focus on how scan results (typically stored in XML files) are imported into the DB Calibration Tables.
Note that, for each Calibration Table, there is a corresponding IMPORT table, that keeps track of the process of uploading itself, containing the time at which the corresponding table was updated (i.e. the time-stamp recorded by the upload tool) and the run-number(s) stored in the XML result files (i.e. the calibration run(s) from which those results were obtained):
These tables contain only one entry per run-type (the run-type is also used as the main key): the time-stamp of the last upload and the run-number(s) of the run(s) with which the calibration results were obtained.
The uploading is performed with a dedicated tool. The detailed documentation concerning this tool can be found on Karol's Tools twiki page, or directly in the Calibration Upload Tool Manual. The upload tool uses as input an XML scan-result file and modifies the values of the calibration parameters listed in there, generating automatically a detailed log file. Its usage is restricted to users with the appropriate privileges.
As a sanity check, the tool also displays all known information about the calibration run(s) on which the results in the XML result files are based (Run-#, Run-Type, recipe name, date & time, SiPM over-voltage and temperature, PACIFIC configuration etc.) and asks the user to confirm that this is all as expected before proceeding to upload the results to the Online DB.
An overview of how this is performed is shown in the figure below.
Figure 4. Overview of the process to upload calibration results into the Online DB Calibration Tables.
It is worth noting a number of design features concerning the process of storing calibration results:
calibration tables contain only the last estimates of the best value of all parameters, and no history of how they were modified in the course of time;
when no new estimate of the best value of a certain parameter is found in the XML result files, the previous best estimate of that parameter is placed in the calibration table; no track of this event is kept in the DB (but a warning is issued by the upload tool);
calibration-import tables contain only the last modification date for each calibration-run type and no history of the modifications;
if one wants to perform historical searches or systematic studies, then one need a dedicated study of the XML result files and of the upload-tool log file.
Using the Calibration Tables to create new Recipes
Every time the Recipe Creator creates a new recipe, it makes use of the best values of all parameters contained in each Calibration Table.
For each calibration table, a number of actions are undertaken by the Recipe Creator:
if an expected parameter value is not found in the appropriate calibration table, a warning is issued and a pre-defined default value is used;
read from the corresponding calibration-import table the run number(s) and the last-upload time-stamp and store them in the Recipe Creation Table;
display relevant information about the calibration table, namely:
the run number(s) and the upload time-stamp from the corresponding calibration-import table;
the SiPM temperature and over-voltage and the PACIFIC configuration with which the calibration results were obtained (these are obtained from the Calibration Run Table, using the run number(s) from the corresponding calibration-import table);
check the consistency of the SiPM temperature and over-voltage and of the PACIFIC configuration:
the SiPM temperature and over-voltage and the PACIFIC configuration chosen by the recipe creator have to be consistent with those with which the calibration results were obtained;
the SiPM temperature and over-voltage and the PACIFIC configuration have to be consistent with those of all the other calibration tables.
An overview of how these actions are performed is shown in the figure below.
Figure 5. Overview of the process to use calibration results from the Online DB Calibration Tables to create new recipes.
Calibration Parameters and Recipes Application at Run-Time
Every time a recipe is applied, it will make use of the best values of the calibration parameters previously copied from the Calibration Table into the recipe itself.
For each calibration table, a number of consistency checks are performed by a run-time WinCC Control Manager:
Retrieve and display the time stamp and the run number(s) from the corresponding Calibration Import table;
for all run numbers, display a log of the information in the Calibration Run Table:
Time Stamp;
Run Type;
Recipe used to take the run;
the SiPM temperature and over-voltage and the PACIFIC configuration with which the calibration results were obtained;
check that the time-stamp of last modification stored in the Calibration Import table is not more recent than that of the recipe currently being applied (if not, issue warning in alarm table);
check that the SiPM temperature and over-voltage are consistent with the real-time ones of the detector (if not, issue warning in alarm table).
Figure 6. Run-time Application of the process calibration results and consistency checks.
Overview of a complete calibration cycle
The full cycle through which a calibration run is taken, its results analyzed and stored in the calibration tables, then used to create new recipes and finally applied to the detector hardware, is summarized in the figure below.
Figure 7. Overview of the complete cycle necessary to perform and apply a calibration.
Recipe Creation Table
Every time the Recipe Creator creates a new recipe, a new entry is added to a dedicated table, called the Recipe Creation Table. Beside the creation time-stamp, this table contains the key ingredients used to create the recipe itself. Although all hardware settings contained in the recipe could be retrieved from the FSM Configuration DB, the Recipe Creation Table allows the quick retrieval of the key recipe ingredients and a consistency check w.r.t. actual run conditions.
Recipe-Creation Table Structure
Recipe-Creation table entries are uniquely indexed by the recipe name and the time stamp of creation. They contain the last-modification date of all tables used by the Recipe Creator to build the recipe as well as the choices made by the user, i.e. the run type, the threshold values in photo-electrons and the SiPM temperature and over-voltage.
RECIPE_CREATION
RECIPE_CREATION: Key = Recipe Name and Time-Stamp, as many entries as recipes created
. For the operation of the SciFi online system, a number of additional DataBases are necessary.
The overall design of the SciFi Online DataBase is described in SciFi Online Databases EDMS Doc. 2050116
jpg 
pdf 
png 
Copyright &© 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.