-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fake comparison failures due to L1T in wf 25202.0 and 1330.0 #29237
Comments
assign l1 |
New categories assigned: l1 @benkrikler,@rekovic you have been requested to review this Pull request/Issue and eventually sign? Thanks |
A new Issue was created by @silviodonato Silvio Donato. @Dr15Jones, @smuzaffar, @silviodonato, @makortel, @davidlange6, @fabiocos can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
cc: @srimanob |
Thanks @silviodonato |
try with https://tinyurl.com/ubwjuu6 |
I'm sorry for taking so long to get back on this issue. I'm unfortunately not very proficient with global tags. The issue is rather tricky. It affects MC simulation with Run2_2016 era, and with the default global tags in both 10_6_X and 11_1_X, after the latest EMTF fixes. To provide some background, during the UL16 production, the global tag for 2016 was updated to have the correct tags (see [1], Feb 2020). As a consequence, it broke the EMTF emulator, because the software (both sides of python & C++) was not set up correctly. It was set up to emulate the latest firmware (i.e. Run2_2018 at the moment). Andrew & Efe have submitted PRs to fix the issue (see [2] and [3] for 11_1_X). The results were verified using the latest UL16 RelVals [4]. So I mentioned that the change of the GT was what broke the EMTF. But in both 10_6_X and 11_1_X when you execute 'runTheMatrix', the 'auto' global tags are not updated. In 10_6_11, 'auto:run2_mc' points to '106X_mcRun2_asymptotic_v9' [5] which has the correct EMTF tags for Run2_2018; in 11_1_0_pre4, it points to '110X_mcRun2_asymptotic_v7' [6] which has the correct EMTF tags for Run2_2018. That means that, out of the 'runTheMatrix' results, those with Run2_2018 era are correct, but those with Run2_2016 are incorrect. Currently, only two processes ('1330.0' and '25202.0') are using '--era Run2_2016', so they are the ones affected. This became an issue after the latest EMTF fixes mentioned above. Prior to that, the software (both python & C++) always expected the EMTF tags for Run2_2018; but now it expects different tags for 2016 and for 2017/18. As a side note, the results with Run2_2017 era are also somewhat incorrect. But because EMTF uses the same BDT trees (meaning the same L1TMuonEndCapForestRcd tag) in 2017 & 2018, this doesn't break the EMTF emulator, although certain parameters are not exactly correct. I don't know what is the correct solution. I believe the 'runTheMatrix' workflows should be using the appropriate global tags for different eras. I don't know how the other subsystems are dealing with this, as I'm sure EMTF is not the first one to come across this issue. Please let us know if you have any suggestions and recommendations. Thank you very much! [1] https://indico.cern.ch/event/880783/contributions/3745327/attachments/1985198/3307604/2020_02_11_GTs.pdf Notifications: @abrinke1 @efeyazgan @rekovic @davignon @BenjaminRS |
assign alca |
New categories assigned: alca @christopheralanwest,@tlampen,@pohsun,@tocheng you have been requested to review this Pull request/Issue and eventually sign? Thanks |
run2_mc auto-GT is supposed to be used only for 2016. So, if run2_mc contains a payload that works only for 2018, it is a problem and the GT should be updated. |
Ah, I didn't realize that. So the comment in the Then I think, for 10_6_X, 'auto:run2_mc_pre_vfp' and 'auto:run2_mc' should be updated to point to '106X_mcRun2_asymptotic_preVFP_v6' and '106X_mcRun2_asymptotic_v12' as used in the latest UL16 RelVals [1,2]. For 11_1_X, new global tags might need to be created? [1] https://dmytro.web.cern.ch/dmytro/cmsprodmon/workflows.php?campaign=CMSSW_10_6_11_CANDIDATE3__hltul16_pre-1585301830 |
Appears that the same problem is causing address sanitizer (ASAN) failures (#29332) in a scale which makes it hard to spot other issues with ASAN. Could this issue be addressed soon? Thanks. |
Hi @jiafulow @christopheralanwest @tlampen @tocheng Could you please have a look? Thanks. |
The latest 10_6_X GTs for 2016 MC are:
These differ from the GTs you suggested by the addition of an updated https://cms-conddb.cern.ch/cmsDbBrowser/diff/Prod/gts/106X_mcRun2_asymptotic_preVFP_v6/106X_mcRun2_asymptotic_preVFP_v8 Are the tags in the latest GTs the correct tags to be used in 10_6_X and later? I'm asking because the move from Should the cosmics GT also be updated with the changes? After receiving a response, I can make a PR for master and the appropriate backports. |
@christopheralanwest I believe it's ok to use the latest GTs that you listed. I checked that Would you also be able to update the 11_1_X GTs? I'm not sure if there are 11_1_X GTs with the correct |
@jiafulow Could you also confirm that the 2016 cosmics GT should be updated in the same way as the collision GTs? The differences between the latest cosmic and collision GTs for 2016: is larger than it had been previously: Could you confirm that the only difference between L1T tags the pp collision and cosmics GTs are in the following records:
|
@christopheralanwest I'm not familiar with any of the listed records, so I don't think I know how to answer the question. Maybe @davignon or other L1T experts could help? |
@davignon @bundocka Could you respond to the question at #29237 (comment)? Thanks. |
@christopheralanwest @jiafulow L1TCaloParamsRcd:
L1TMuonEndCapForestRcd:
L1TMuonEndCapParamsRcd:
L1TMuonGlobalParamsRcd:
L1TUtmTriggerMenuRcd:
Regarding your question:
I'm afraid I don't know the answer... Maybe @dildick or @gekobs or @dinyar know? Best, |
For 2016 cosmics (MC), for L1TMuonEndCapForestRcd and L1TMuonEndCapParamsRcd, please use Sorry that I didn't answer this in my earlier reply. |
Sorry for the delay. I confirm that L1TMuonGlobalParams_static_UL2016v2_mc should be used. For the question "Could you confirm that the only difference between L1T tags the pp collision and cosmics GTs are in the following records: [...]" I'm afraid I also don't know the answer. |
Could someone comment briefly the status of the fix? Thanks. |
@jiafulow @christopheralanwest @davignon @dinyar What is the status of the fix? Are you going to update these records in the 111X and 112X GT? |
Hi - may I ask few questions on GT update(w/ correct L1T tags)?
Thanks, |
Do I understand correctly that these changes are needed for 11_0_X, 11_1_X and 11_2_X? If so, you can queue the tags to:
Since no other changes have been made to these GTs since 110X, we can then use the 110X GTs for all three release series. Please queue the tags and create the candidate GTs. Thanks. |
…29237 Updated L1T tags to address CMSSW issue #29237
After #30151, everything seems to work properly |
…29237-11_1_X Updated L1T tags to address CMSSW issue #29237 [11_1_X]
…29237_11_0_X Updated L1T tags to address CMSSW issue #29237 [11_0_X]
…29237-10_6_X Updated L1T tags to address CMSSW issue #29237 [10_6_X]
+1 This is resolved by #30151 and backports |
thanks |
We are observing fake comparison failures in wf 25202.0 and 1330.0 since CMSSW_11_1_X_2020-03-17-2300 [1].
The failures are in folders L1TEMU/L1TdeStage2uGMT, L1T/L1TStage2uGMT, L1T/L1TriggerVsGen.
Example: L1T / L1TStage2uGMT / EMTFInput
Likely, this fake error is related to #29080 .
[1] https://cmsweb.cern.ch/dqm/dev/session/6Stmgn
The text was updated successfully, but these errors were encountered: