Synchronize L1T scales that are not set correctly online.

[mulhearn]

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.

[mulhearn]

@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.

[jimbrooke]

I strongly suspect the legacy DB contains out of date values.

[mulhearn]

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?

[koskot77]

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.

[jimbrooke]

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.

[mulhearn]

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.

[mulhearn]

This seems to have stalled... I pinged the experts again...

[mulhearn]

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

[mulhearn]

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  

[mulhearn]

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?

[kkotov]

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' ;

[mulhearn]

@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.

[mulhearn]

@kkotov violated causality!

[mulhearn]

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.

[kkotov]

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.

[mulhearn]

Just noticed that the scales here are via the legacy GCT.

[mulhearn]

Just noting that @jimbrooke has promised to update the online configuration appropriately at his leisure.