QIE calibration conditions

[awhitbeck]

We need to start developing a conditions object that will allow digitization constants to be stored in a database and not be hardcoded in SimQIE. These constants include:

• SiPM gain
• number of bins per range -- this is 5 numbers (though I think it only need to be four) but it is the same for all channels and will never change.
• bin edges (17 of these per channel)
• bin slopes (16 of these per channel)
• TDC_threshold
• pedestal mean
• pedestal width
• SiPM noise rate

These will have per channel numbers eventually, but for now, we only ever use one set, the hardcoded set. More than this, I cannot say at the moment what this code will look like...

(@tomeichlersmith )

[tomeichlersmith]

Currently the ECal Trig Prims use a single hardcoded set of calibration constants and the calibration system. This allows for easier update to changes per channel number in the future. In this comment, I will try to point out the necessary parts that the ECal Trig Prims uses from the Conditions system.

Python Configuration

ECal Trig Prims has a set of hardcoded conditions here: ecal_hardcoded_conditions.py inside of Ecal/python. Then, in a python config that you want to run the digis with you add the line import LDMX.Ecal.ecal_hardcoded_conditions which imports and registers the conditions in that python module.

Comments

• The first argument of the constructor is the name of the condition, you will need this to exactly match the name used in the C++
• Notice that the names of the parameters are the column names (provided in a list to the constructor)
• The validForAllRows function means to use the input values for all channel IDs (this is what you want)
• Jeremy used an Integer table for ECal Trig Prims (because that's more realistic), but we also have a double table available with SimpleCSVDoubleTableProvider

Use in Processor

In the C++, all of the following code is in produce (or in functions called by produce). In ECal, Jeremy gives the conditions table to a helper class which calculates the necessary trig prim objects.

These lines call the helper class HgcrocTriggerCalculations (which is in Tools because HCal will use it in the future).

The code to get your csv table is

const DoubleTableCondition& my_csv_table = getCondition<DoubleTableCondition>("name_that_matches_python");

The code to get a parameter from the table is the following:

digi_constant = my_csv_table.get(channel_id,column_index);

Since searching through the column names to find the column index is an expensive process, it is highly recommended to cache a map of column names to column indices and only call get with the column index. You can use the function getColumnNumber to get the index of the column:

column_index = my_csv_table.getColumnNumber(column_name);

Comments

• This is overkill for things that are constant across all channel IDs, but will allow you to update to values that change depending on the ID without changing the C++. You would only have to import LDMX.TrigScint.some_complicated_conditions_table in your python config instead of importing the constant conditions.
• In HgcrocTriggerCalculations, Jeremy hardcodes the column name/index mapping into a wrapper class that helps access the conditions table. You don't have to do this if you don't want to, but the caching of the column indices is necesssary.