Open mulhearn opened 8 years ago
@kkotov @jimbrooke Khristian, can you track down why these are not set correctly online? Do we need a new O2O or just need to update the legacy online DB with modern values? Not sure what the correct solution is.
I strongly suspect the legacy DB contains out of date values.
OK, so is the operational plan that we should just keep these up to date online? Presumably these are just hardcoded in the online hardware then?
select TSC_KEY from CMS_TRG_L1_CONF.L1_CONF_DETAILS_VIEW where L1_KEY like 'L1_20151016_064615_10390' ; select GCT_KEY from CMS_TRG_L1_CONF.TRIGGERSUP_CONF where TS_KEY like 'TSC_20151008_003499_cosmics_BASE' ; select GCT_PHYS_PARAMS_KEY from CMS_GCT.GCT_CONFIG where CONFIG_KEY like 'V38_14_Ext40_2015_03_17_JetSeedThresh5GeV_Add9Lat_Orsc_Sub14'; select GCT_SCALES_KEY from CMS_GCT.GCT_PHYS_PARAMS where CONFIG_KEY like 'GCTPhysics_2012_04_27_JetSeedThresh5GeV' ; select SC_HTM_FK from CMS_GT.L1T_SCALES where ID like 'L1T_Scales_20101224' ; select E_GEV_BIN_LOW_0 from CMS_GT.L1T_SCALE_HTM_ENERGY where ID like 'L1T_ScaleHTM_20091006' ;
This is a sequence of queries navigating from the top-level L1_KEY down to the suspected scales. As you can see, the thresholds' key dates back to 2009. I am not sure why this is the case, but I see the L1T O2O correctly takes these old thresholds and pushes them to the CondDB. Now I wonder which of the keys was not updated in the online configs.
Yes, I think the correct fix is to put the new values in the online DB, then they will be O2O’d, and then if possible patch up the IOVs to match the data already taken. I guess someone from GT can create the new online scales.
On 19 Oct 2015, at 12:30, koskot77 notifications@github.com<mailto:notifications@github.com> wrote:
select TSC_KEY from CMS_TRG_L1_CONF.L1_CONF_DETAILS_VIEW where L1_KEY like 'L1_20151016_064615_10390' ; select GCT_KEY from CMS_TRG_L1_CONF.TRIGGERSUP_CONF where TS_KEY like 'TSC_20151008_003499_cosmics_BASE' ; select GCT_PHYS_PARAMS_KEY from CMS_GCT.GCT_CONFIG where CONFIG_KEY like 'V38_14_Ext40_2015_03_17_JetSeedThresh5GeV_Add9Lat_Orsc_Sub14'; select GCT_SCALES_KEY from CMS_GCT.GCT_PHYS_PARAMS where CONFIG_KEY like 'GCTPhysics_2012_04_27_JetSeedThresh5GeV' ; select SC_HTM_FK from CMS_GT.L1T_SCALES where ID like 'L1T_Scales_20101224' ; select E_GEV_BIN_LOW_0 from CMS_GT.L1T_SCALE_HTM_ENERGY where ID like 'L1T_ScaleHTM_20091006' ;
This is a sequence of queries navigating from the top-level L1_KEY down to the suspected scales. As you can see, the thresholds' key dates back to 2009. I am not sure why this is the case, but I see the L1T O2O correctly takes these old thresholds and pushes them to the CondDB. Now I wonder which of the keys was not updated in the online configs.
— Reply to this email directly or view it on GitHubhttps://github.com/cms-l1t-offline/cmssw/issues/64#issuecomment-149177551.
In terms of urgency, I guess this doesn't in principle need to fixed by Monday (CMSSW release deadline) because the MC tags are correct, but we should obviously get this in quickly anyway.
This seems to have stalled... I pinged the experts again...
Summary of email exchange between Takashi, Vasile, and me:
1) All scales except L1HfRingEtScaleRcd and L1HtMissScaleRcd are bitwise the same in MC tags and data tags (output of the O2O).
2) The L1HfRingEtScaleRcd is (re)used for Isolated Taus. GT understands the correct values to be:
Et Threshold Scale:
0x0: 0
0x1: 24
0x2: 28
0x3: 32
0x4: 36
0x5: 40
0x6: 44
0x7: 48
3) L1HtMissScaleRcd is used for MHT/HT. GT understand the correct scales to be:
0x0: 0
0x1: 0.01
0x2: 0.02
0x3: 0.03
....
0x7f: 1.269999
0x80: 1.279999
however, these are not currently used in any implemented trigger. 4) The current MC tag for the RingEtScale is L1HfRingEtScale_stage1_25ns_mc, which agrees exactly with GT. 5) The current MC tag for L1HtMissScaleRcd is L1HtMissScale_stage1_25ns_mc, which does not agree with GT, and seems to include updated values, which were never actually used:
L1CaloEtScale :
Input scale max = 0
Input LSB = 0.5 GeV
Rank scale max = 127
Threshold 0 = 0 GeV
Threshold 1 = 0.00787402 GeV
Threshold 2 = 0.015748 GeV
Threshold 3 = 0.023622 GeV
Threshold 4 = 0.0314961 GeV
...
Threshold 123 = 0.968504 GeV
Threshold 124 = 0.976378 GeV
Threshold 125 = 0.984252 GeV
Threshold 126 = 0.992126 GeV
Threshold 127 = 1 GeV
6) The local config file has identical content as the MC tag, see here: https://github.com/cms-l1t-offline/cmssw/blob/l1t-muon-CMSSW_7_6_0_pre5/L1Trigger/L1TCalorimeter/python/L1TCaloStage1_cff.py
7) The (unused by everyone) data tags (i.e. the output of O2O) have for L1HfRingEtScale:
Dumping L1HfRingEtScale:
L1CaloEtScale :
Input scale max = 255
Input LSB = 0.5 GeV
Rank scale max = 7
Threshold 0 = 0 GeV
Threshold 1 = 2 GeV
Threshold 2 = 3 GeV
Threshold 3 = 4 GeV
Threshold 4 = 6 GeV
Threshold 5 = 50 GeV
Threshold 6 = 200 GeV
Threshold 7 = 500 GeV
8) The (unused by everyone) data tags (i.e. the output of O2O) have for L1HtMissScale:
Dumping L1HtMissScale:
L1CaloEtScale :
Input scale max = 0
Input LSB = 0.5 GeV
Rank scale max = 127
Threshold 0 = 0 GeV
Threshold 1 = 2 GeV
Threshold 2 = 4 GeV
Threshold 3 = 6 GeV
...
Threshold 123 = 246 GeV
Threshold 124 = 248 GeV
Threshold 125 = 250 GeV
Threshold 126 = 252 GeV
Threshold 127 = 254 GeV
9) Looking at hash tables in cond DB, I see that these are the legacy values, going at least all the way back to 2008:
mulhearn@lxplus0042>conddb list L1HfRingEtScale_CRAFT09_hlt
[2015-11-03 14:28:19,363] INFO: Connecting to pro [frontier://PromptProd/cms_conditions]
[2015-11-03 14:28:19,762] INFO: Listing with a limit of 500 IOVs, starting from the highest since. If you need to see more, please increase the limit of returned results.
Since: Run Insertion Time Payload Object Type
----------- ------------------- ---------------------------------------- -------------
202306 2008-01-01 00:00:42 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
202310 2008-01-01 00:00:42 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
202315 2008-01-01 00:00:42 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
202317 2008-01-01 00:00:42 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
...
220390 2008-01-01 00:00:42 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
227695 2015-01-30 09:45:38 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
227761 2015-01-30 09:45:38 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
227881 2015-01-30 09:45:38 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
228151 2015-01-30 09:45:38 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
228186 2015-01-30 09:45:38 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
228410 2015-01-30 09:45:38 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
251530 2015-07-11 15:22:32 036148d374ade9ba6830bb0b8f2058d6f06dfdd3 L1CaloEtScale
251535 2015-07-11 15:49:23 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
251565 2015-07-12 09:31:04 036148d374ade9ba6830bb0b8f2058d6f06dfdd3 L1CaloEtScale
251587 2015-07-12 14:34:47 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
251605 2015-07-12 17:27:52 036148d374ade9ba6830bb0b8f2058d6f06dfdd3 L1CaloEtScale
251608 2015-07-12 18:54:12 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
251614 2015-07-12 20:44:55 036148d374ade9ba6830bb0b8f2058d6f06dfdd3 L1CaloEtScale
251622 2015-07-13 04:48:15 5013103d90053732ce62bfae71cc75cda8f43a54 L1CaloEtScale
Note that the different hashes at the end 0361... vs 5013... are an extremely annoying feature that the hash code for identical payloads changes, even for identical content, if the boost library version changes. Makes this type of output almost useless actually...
10) Similar results for
conddb list L1HfRingEtScale_CRAFT09_hlt
[2015-11-03 14:32:49,691] INFO: Connecting to pro [frontier://PromptProd/cms_conditions]
[2015-11-03 14:32:50,086] ERROR: There is no tag or global tag named mulhearn@lxplus0042 in the database.
mulhearn@lxplus0042>conddb list L1HtMissScale_CRAFT09_hlt
[2015-11-03 14:33:08,281] INFO: Connecting to pro [frontier://PromptProd/cms_conditions]
[2015-11-03 14:33:09,990] INFO: Listing with a limit of 500 IOVs, starting from the highest since. If you need to see more, please increase the limit of returned results.
Since: Run Insertion Time Payload Object Type
----------- ------------------- ---------------------------------------- -------------
202306 2008-01-01 00:00:42 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
202310 2008-01-01 00:00:42 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
...
228410 2015-01-30 09:45:43 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
251530 2015-07-11 15:22:32 ec411ed4ce1308c0527a88b7de8745e5be8a0788 L1CaloEtScale
251535 2015-07-11 15:49:23 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
251565 2015-07-12 09:31:04 ec411ed4ce1308c0527a88b7de8745e5be8a0788 L1CaloEtScale
251587 2015-07-12 14:34:47 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
251605 2015-07-12 17:27:52 ec411ed4ce1308c0527a88b7de8745e5be8a0788 L1CaloEtScale
251608 2015-07-12 18:54:13 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
251614 2015-07-12 20:44:55 ec411ed4ce1308c0527a88b7de8745e5be8a0788 L1CaloEtScale
251622 2015-07-13 04:48:15 6ba9ced3eed48b446f619249a08c35bdff5f82f1 L1CaloEtScale
To summarize, the only discrepancies are:
1) It appears for MC we introduced new scales for HT/MHT (L1HfRingEtScale_CRAFT09_hlt) that were never actually used in the L1 Menu implementation. We should check with @apana et al. if there is any plan to use these scales in the future and which one we should use for MC in either case.
2) It appears that the O2O of both HT/MHT (L1HfRingEtScalr) and Isolated Tau ( (L1HfRingEtScale) is still outputting the legacy values from 2008 or earlier. At the moment, no one cares at all about this because the values are being overridden by local config file for both MC and data in all stage-1 work flows. But clearly it should still be fixed. It follows that there is some disconnect between what O2O is outputting and what GT understands to be at the input. Perhaps there was some update to O2O needed to fetch the new values? Or perhaps there is some mistake in the subsystem keys?
Here I reiterate in more detail my earlier comment in this thread. The O2O payload associated with L1HtMissScaleRcd record is produced by: https://github.com/kkotov/cmssw/blob/extended-l1o2o/L1TriggerConfig/L1ScalesProducers/src/L1HtMissScaleOnlineProd.cc This code shows the thresholds are queried as E_GEV_BINLOW* columns of the CMS_GT.L1T_SCALE_HTM_ENERGY. It can be reduced to a simple SQL query:
select E_GEV_BIN_LOW_3, E_GEV_BIN_LOW_4, E_GEV_BIN_LOW_5, E_GEV_BIN_LOW_6 from CMS_GT.L1T_SCALE_HTM_ENERGY where ID like 'L1T_ScaleHTM_20091006' ;
gives:
E_GEV_BIN_LOW_3 E_GEV_BIN_LOW_4 E_GEV_BIN_LOW_5 E_GEV_BIN_LOW_6
6 8 10 12
The ID key for this table dates back to 2009. The key can be queried independently:
select ID from CMS_GT.L1T_SCALES, CMS_GCT.GCT_PHYS_PARAMS, CMS_GCT.GCT_CONFIG, CMS_TRG_L1_CONF.TRIGGERSUP_CONF, CMS_TRG_L1_CONF.L1_CONF_DETAILS_VIEW where L1T_SCALES.ID = GCT_PHYS_PARAMS.GCT_SCALES_KEY and GCT_PHYS_PARAMS.CONFIG_KEY = GCT_CONFIG.GCT_PHYS_PARAMS_KEY and GCT_CONFIG.CONFIG_KEY = TRIGGERSUP_CONF.GCT_KEY and TRIGGERSUP_CONF.TS_KEY = L1_CONF_DETAILS_VIEW.TSC_KEY and L1_CONF_DETAILS_VIEW.L1_KEY like 'L1_20151016_064615_10390' ;
@kkotov can you look at bit more underneath the hood of the legacy L1HFRingEtScale online producer and determine (1) what sub-system key is being O2O'ed for the latest payloads, and (2) what precise fields in online DB are being queried to extract these values? Once we have this, we can compare notes with the online team.
@kkotov violated causality!
The findings of Khristian are that even in recent L1 trigger keys like "L1_20151016_064615_10390" the L1 scales are old: "L1T_ScaleHTM_20091006". This is consistent with what we find in terms of output.
A small correction L1HfRingEtScaleRcd -> L1HtMissScaleRcd, that I made above should be completed with the similar description for L1HfRingEtScaleRcd that is generated by: https://github.com/kkotov/cmssw/blob/extended-l1o2o/L1TriggerConfig/L1ScalesProducers/src/L1HfRingEtScaleOnlineProd.cc
The corresponding key is queried with:
select SC_HF_ET_SUM_FK from CMS_GT.L1T_SCALES , CMS_GCT.GCT_PHYS_PARAMS, CMS_GCT.GCT_CONFIG, CMS_TRG_L1_CONF.TRIGGERSUP_CONF, CMS_TRG_L1_CONF.L1_CONF_DETAILS_VIEW where L1T_SCALES.ID = GCT_PHYS_PARAMS.GCT_SCALES_KEY and GCT_PHYS_PARAMS.CONFIG_KEY = GCT_CONFIG.GCT_PHYS_PARAMS_KEY and GCT_CONFIG.CONFIG_KEY = TRIGGERSUP_CONF.GCT_KEY and TRIGGERSUP_CONF.TS_KEY = L1_CONF_DETAILS_VIEW.TSC_KEY and L1_CONF_DETAILS_VIEW.L1_KEY like 'L1_20151016_064615_10390' ;
which gives SC_HF_ET_SUM_FK = L1T_ScaleHFETSum_20080922 For this key we observe the following thresholds:
select E_GEV_BIN_LOW_3, E_GEV_BIN_LOW_4, E_GEV_BIN_LOW_5, E_GEV_BIN_LOW_6 from CMS_GT.L1T_SCALE_HF_ET_SUM where ID like 'L1T_ScaleHFETSum_20080922' ;
E_GEV_BIN_LOW_3 E_GEV_BIN_LOW_4 E_GEV_BIN_LOW_5 E_GEV_BIN_LOW_6 4 6 50 200
I.e. the input OMDS thresholds for the L1HfRingEtScaleRcd and L1HtMissScaleRcd payloads match exactly what Mike sees offline. Q.E.D.
Just noticed that the scales here are via the legacy GCT.
Just noting that @jimbrooke has promised to update the online configuration appropriately at his leisure.
Dustins tool in issue #42 reveals the following tables containing L1 scales are discrepant between data and MC global tags:
L1HtMissScaleRcd L1HfRingEtScaleRcd
Printing the tables directly reveals that the MC global tags has the correct (stage 1) values:
Dumping L1HtMissScale:
L1CaloEtScale : Input scale max = 0 Input LSB = 0.5 GeV Rank scale max = 127 Threshold 0 = 0 GeV Threshold 1 = 0.00787402 GeV Threshold 2 = 0.015748 GeV Threshold 3 = 0.023622 GeV Threshold 4 = 0.0314961 GeV Threshold 5 = 0.0393701 GeV ... Dumping L1HfRingEtScale:
L1CaloEtScale : Input scale max = 255 Input LSB = 0.5 GeV Rank scale max = 7 Threshold 0 = 0 GeV Threshold 1 = 24 GeV Threshold 2 = 28 GeV Threshold 3 = 32 GeV Threshold 4 = 36 GeV Threshold 5 = 40 GeV Threshold 6 = 44 GeV Threshold 7 = 48 GeV
While the data tags still contain the legacy scales.
For now, we are leaving the customization for Stage 1 that sets these correctly from config file. A fix online will be needed before we can turn this off.
We will track the resolution here.