Mapping DB Proposal

Proposal

We propose to add a new set of tables to the Calibrations_emc database that will track the electronics mapping for the BEMC, BSMD, and BPRS and allow for an alternative implementation of StEmcDecoder.

Motivation

The existing BEMC electronics mapping code (StDaqLib/EMC/StEmcDecoder) has become difficult to maintain. Each time we discover something about the BEMC that requires an update to our lookup tables we have to decipher the algorithms that generate these lookup tables, and more often than not our first guess about how to add the new information is wrong.

StEmcDecoder is also inefficient because it doesn’t track the validity range of the current lookup tables and so it rebuilds the tables every event. Analysis jobs spend a non-neglible amount of CPU time rebuilding these decoder tables.

The information in the decoder is critical for BEMC experts, but the interface to that information is less than ideal. StEmcDecoder does not even have CINT bindings. An SQL interface would allow for much easier debugging.

For the End User

We are preserving the StEmcDecoder interface and reimplementing it to use the DB tables. Offline users should see a seamless transition. StEmcDecoder also plays an important role in the online p-plots. We’ll need to find a solution that allows access to the DB tables in that framework.

For Experts

The new mapping tables will contain a row for each detector element, so we expect that querying the tables using SQL will prove to be a valuable debugging tool. A simplified query might look like:

SELECT elementID,m,e,s FROM bemcMapping WHERE triggerPatch=5 and beginTime='2007-11-01 00:00:00';

which would yield

+-----------+------+------+------+
| elementID | m | e | s |
+-----------+------+------+------+
| 1709 | 43 | 9 | 2 |
| 1710 | 43 | 10 | 2 |
| 1711 | 43 | 11 | 2 |
| 1712 | 43 | 12 | 2 |
| 1729 | 44 | 9 | 1 |
| 1730 | 44 | 10 | 1 |
| 1731 | 44 | 11 | 1 |
| 1732 | 44 | 12 | 1 |
| 1749 | 44 | 9 | 2 |
| 1750 | 44 | 10 | 2 |
| 1751 | 44 | 11 | 2 |
| 1752 | 44 | 12 | 2 |
| 1769 | 45 | 9 | 1 |
| 1770 | 45 | 10 | 1 |
| 1771 | 45 | 11 | 1 |
| 1772 | 45 | 12 | 1 |
+-----------+------+------+------+
16 rows in set (0.12 sec)

Previously, we needed to write one-off compiled programs to export this kind of information out of the decoder.

Draft IDLs

struct emcMapping {
octet m; /* module 1-120 */
octet e; /* eta index 1-20 */
octet s; /* sub index 1-2 */
unsigned short daqID; /* ordering of elements in DAQ file 0-4799 */
octet crate; /* electronics crates 1-30 */
octet crateChannel; /* index within a crate 0-159 */
octet TDC; /* index in crate 80, 0-29 */
unsigned short triggerPatch; /* tower belongs to this TP 0-299 */
octet jetPatch; /* tower belongs to this JP 0-11 */
unsigned short DSM; /* just integer div TP/10 0-29 */
float eta; /* physical pseudorapidity of tower center */
float phi; /* physical azimuth of tower center */
char comment[255];
}
struct smdMapping {
octet m; /* module 1-120 */
octet e; /* eta index 1-150 (eta), 1-10 (phi) */
octet s; /* sub index 1 (eta), 1-15 (phi) */
octet rdo; /* readout crate 0-7 */
unsigned short rdoChannel; /* index in crate 0-4799 */
octet wire; /* wire number 2-80 */
octet feeA; /* A value for FEE 1-4 */
float eta; /* physical pseudorapidity of strip center */
float phi; /* physical azimuth of strip center */
char comment[255];
}
struct prsMapping {
octet m; /* module 1-120 */
octet e; /* eta index 1-20 */
octet s; /* sub index 1-2 */
octet PMTbox; /* PMT box 1-30 (West), 31-60 (East) */
octet MAPMT; /* MAPMT # for this element in PMTbox 1-5 */
octet pixel; /* index inside MAPMT 1-16 */
octet rdo; /* readout crate 0-3 */
unsigned short rdoChannel; /* index in readout crate 0-4799 */
octet wire; /* wire number 1-40 */
octet feeA; /* A value for FEE 1-2 */
octet SCA; /* switched capacitor array 1-2 */
octet SCAChannel; /* index inside SCA 0-15 */
octet powerSupply; /* 1-2 */
octet powerSupplyModule; /* 1-15 */
octet powerSupplyChannel; /* 0-14 */
float eta; /* physical pseudorapidity of tower center */
float phi; /* physical azimuth of tower center */
char comment[255];
}

I also proposed MySQL schemata on my blog, but I guess in STAR these IDLs define the schema.

Performance Estimates

I’ve temporarily installed tables on our MIT mirror and filled them with data describing the 2008 BEMC electronics mapping. Here are the stats:

*************************** 1. row ***************************
Name: bemcMapping
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 4800
Avg_row_length: 55
Data_length: 268732
Max_data_length: 281474976710655
Index_length: 163840
Data_free: 0
Auto_increment: 4801
Create_time: 2008-11-14 16:03:51
Update_time: 2008-11-14 16:05:45
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
*************************** 2. row ***************************
Name: bprsMapping
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 4800
Avg_row_length: 70
Data_length: 336036
Max_data_length: 281474976710655
Index_length: 165888
Data_free: 0
Auto_increment: 4801
Create_time: 2008-11-14 17:52:53
Update_time: 2008-11-14 17:59:40
Check_time: 2008-11-14 17:52:53
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
*************************** 3. row ***************************
Name: bsmdeMapping
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 18000
Avg_row_length: 52
Data_length: 936000
Max_data_length: 281474976710655
Index_length: 604160
Data_free: 0
Auto_increment: 18001
Create_time: 2008-11-14 16:03:51
Update_time: 2008-11-18 01:48:36
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
*************************** 4. row ***************************
Name: bsmdpMapping
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 18000
Avg_row_length: 52
Data_length: 936000
Max_data_length: 281474976710655
Index_length: 604160
Data_free: 0
Auto_increment: 18001
Create_time: 2008-11-14 16:03:51
Update_time: 2008-11-18 02:13:36
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment:
4 rows in set (0.11 sec)

This information is supposed to be static, even from year-to-year. In reality, we discover some details about the mapping each year which will require updates to some of these rows. There should certainly be no intra-run changes, so StEmcDecoder will need to retrieve 4800+4800+18000+18000 rows from the DB for each BFC and user job.

The equivalent C++ array sizes (excluding the comment field as I’m not sure how its handled) will be 101 KB (4800*21) for BEMC, 115 KB (4800*24) for BPRS and 288 KB (18000*16) for each SMD plane.