Fixed algorithm to include BCID in the HLT and included some test algorithm to compare offline and online cells
Fixed algorithm to include BCID in the HLT and included some test algorithm to compare offline and online cells
Merge request reports
Activity
This merge request affects 1 package:
- Trigger/TrigAlgorithms/TrigT2CaloCommon
Adding @damazio as watcher
added Trigger master review-pending-level-1 labels
❎ CI Result FAILURE (hash eee3c748)Athena AthSimulation externals ✅ ✅ cmake ✅ ✅ make ✅ ✅ required tests ⭕ ✅ optional tests ✅ ✅ Full details available on this CI monitor view
✅ Athena: number of compilation errors 0, warnings 0
✅ AthSimulation: number of compilation errors 0, warnings 0
📝 For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 4219]This merge request affects 1 package:
- Trigger/TrigAlgorithms/TrigT2CaloCommon
Adding @damazio as watcher
Maybe @tbold will be able to help me here, specially for the new jobOptions. I don't know how to include the CaloBCIDAvgAlg to always be run when the service is instantiated. Is there a simple way to do it?! For instance, now it is not running for the TrigT2CaloCommon ctests... Thanks, Denis
❎ CI Result FAILURE (hash 9fd3703c)Athena AthSimulation externals ✅ ✅ cmake ✅ ✅ make ✅ ✅ required tests ⭕ ✅ optional tests ✅ ✅ Full details available on this CI monitor view
✅ Athena: number of compilation errors 0, warnings 0
✅ AthSimulation: number of compilation errors 0, warnings 0
📝 For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 4230]Sure Denis, Glad to help. We can add this alg to the set of algorithms that we always do run. Like the IDC cache creators for ID. But a better option would be to add this algorithm in every calo sequence in event context. I think we can start from first approach and then gradually move it whereever it is needed. Is this expensive algorithm to run? Point me to the "usual" config for it?
- Resolved by Frank Winklmeier
Hello @tbold, answering part of your question. This is a conditions algorithm, so, I suppose that during real HLT running, since it depends on the online luminosity, we will probably have it running not very often (after a number of LBs, which I would like to keep it as small as possible - so that we are close to offline), but it is true that we have to invest on a time measurement for its execute method (I am trying to do it now). As for examples of how to make it run, the offline runs it like this : https://acode-browser1.usatlas.bnl.gov/lxr/source/athena/Calorimeter/CaloRec/python/CaloBCIDAvgAlgDefault.py Or like this (for the component accumulator approach) : https://acode-browser1.usatlas.bnl.gov/lxr/source/athena/Calorimeter/CaloRec/python/CaloBCIDAvgAlgConfig.py Maybe we need some special setup to run online or a special configuration to run it not as often as the offline version. Maybe @fwinkl can help here. Also, is there somewhere a tutorial about how to design configurables with this new component accumulator?! I asked many people without a good answer.. Best, Denis
Not sure who "many people" are, but this was covered in the last software developer tutorial: https://indico.cern.ch/event/829411/timetable/?view=standard
I am not sure to which question of Tomasz you referring to and how I can help. Can you please be more specific?
Hello Frank, I am talking about the fact that the luminosity online is not updated in the HLT nodes (I was really not very clear, should not have written over a weekend) as frequently as the offline does. So, my question is how can we emulate this behaviour in reprocessings. I suspect we have to use a specific folder for that.
Hi Denis, About the test failures. The unit test (the thing you run locally typing ctest) is failing due to an error in the L1 menu generation. Independent of you. More interesting is the change of counts in some triggers: http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/ci/CIWebArea/nicos_web_areaMRCIbuilds64BC7G8AthenaOpt/NICOS_TestLog_MR-27155-2019-10-12-17-52/ReleaseTests___Trigger_MT_required-test__Trigger_MT_required-test__m.html The change seems to be at the ID stage in case of electrons & taus but there is a change in XE counts. This is solely calo based. Likely caused by your changes as the differences are subtle.
Have you run these tests as described here: https://atlassoftwaredocs.web.cern.ch/guides/trigger/ ?
Hello Tomasz, thanks for your input. So, between my previous commit and the last one, I enabled by default the BCID offset correction for all calo algorithms. This should be, of course, the default option (except that I am not sure about the algorithm being properly configured to generate the conditions EDM). So, if there are subtle changes in Met results, that seems to go to the right direction. I had checkout a number of packages (including TrigUpgradeTest) and everything passed, but, I did not try this test : runTrigART.py -m -j4 I am trying it now.. Cheers, Denis
two tests failed.. out of 4.. INFO 2 tests succeeded out of 4 executed ERROR ================================================== ERROR The following 2 tests failed: ERROR test_trigAna_q221_RDOtoRDOTrig_mt1_build.sh ERROR test_trigUpgr_full_menu_build.sh ERROR ================================================== For the first there are some count changes (which I am not sure who is the new, who is the old) and the last one has some specific changes (I had not seen the first time).. Cheers, Denis
Edited by Denis Oliveira Damazio