Open rekovic opened 7 years ago
see page 3 of the following slides; https://indico.cern.ch/event/623817/contributions/2520240/attachments/1429860/2195815/20170317.pdf
for invariant mass: you can only apply mass cut
for correlation cut: you can apply cuts on distance e.g. we had "L1_Mu3_JetC120_dEta_Max0p4_dPhi_Max0p4" in 2016 which requires dEta and dPhi at the same time
see the following JIRA ticket concerning distance cuts on invariant mass https://its.cern.ch/jira/projects/CMSLITDPG/issues/CMSLITDPG-45
Hi Vladimir, to answer your questions:
Yes, the uGT fw can combine all of the 4 correlation cut types.
The last stable release of the TME does allow just the use of dEta, dPhi and dR at a time. The next version of the TME will allow all of these cuts together with the MASS cut. The TME development suffered in the last weeks under the time-consuming UTM developments. We hope to catch up very soon
An important issue is, that the TME is extremely entangled with the UTM. We try to develop the UTM to keep pace with the new fw developments and the physics needs. So this back and forth with the UTM versions is certainly preventing us from releasing a compatible TME version.
The last stable release of the TME does allow just the use of dEta, dPhi and dR at a time. The next version of the TME will allow all of these cuts together with the MASS cut. The TME development suffered in the last weeks under the time-consuming UTM developments. We hope to catch up very soon
The restriction is in the level-1 menu grammar defined by UTM not in TME. If the UTM is updated to allow the additional cuts, these cuts can be used without updating TME.
An important issue is, that the TME is extremely entangled with the UTM.
I only see the following dependence on UTM 1) I/O of xml file 2) expression of level-1 algorithms with level-1 menu grammar
These are quite natural couplings. 1) is a step needed to map xml data structure to in-memory data structure. You could use direct python interface to the xml file as the xml schema will not change in future. 2) this is actually a binding between the level-1 menu grammar and the menu editor. You could construct valid level-1 algorithm expression which is compatible with the one defined in UTM without using UTM.
The restriction is in the level-1 menu grammar defined by UTM not in TME. If the UTM is updated to allow the additional cuts, these cuts can be used without updating TME.
No.
@Vladimir: We will integrate these things in the TME.
The restriction is in the level-1 menu grammar defined by UTM not in TME. If the UTM is updated to allow the additional cuts, these cuts can be used without updating TME. No.
You can edit xml file by hand, then any new features available in UTM can be used.
You can edit xml file by hand, then any new features available in UTM can be used.
Sure. But Vladimir explicitly asked for TME support.
@johanneswittmann @tmatsush Current grammar provides two types of correlation functions: mass and distance, with the latter having 3 options (dEta, dPhi, dR) which can be combined. The mass and distance cuts can not be combined and applied at the same time on a given combination. In principle, one could invoke indexing and restrict combinations to particular object indices, and then AND mass and distance conditions, but this might be rather involved when making xml files especially by hand.
In the next version of UTM, could we have a function correlation (or pick a better name) which allows for any combination of the 4 cuts: Mass, dEta, dPhi, dR ?
@johanneswittmann Thanks. Yes, one can create xml files by hand, but certainly it is not the preferred option, and we rather would not have it as the modus operandi. Having TME support for it is certainly much better, if we have any hope of PAGs doing thorough studies tests for optimising the cuts and algos.
@rekovic The UTM implementation utm_0.5.0 already supports using the 3 options (dEta, dPhi, dR) with mass (or _massinv and _masstrv). Len already implemented the emulator code for this feature. So this feature IS already in the new release of the UTM. It is also in the firmware and the emulator vs. firmware has been validated.
The TME is nearly finished. We do not suggest anybody to create XML files by hand. The TME has many checks implemented to prevent faulty XML files.
The next step then on the TME side will be to integrate the overlap removal stuff. The XML file you used (/afs/cern.ch/user/r/rekovic/public/forL1TStage2/l1t-integration/overlap-removal/xml/test_indexing_overlap_removal_v1.xml) is not (and will not be in the future) compatible with the TME and the VHDL producer.
@johanneswittmann As I have already explained in [1] level-1 menu grammar is decoupled from actual implementation of FW/emulator. This implies XML file is also decoupled from FW/emulator implementation, rather it is a collection of parameters needed to instantiate level-1 algorithms. What VHDL producer and emulator should use are enumerations defined in UTM.
utm_0.5.0 [2] has critical problems of changing CondFormat as commented, which should be reverted for not spreading problems and confusions. [by the way, "master" branch is for CMSSW comes with xerces-2.8] The functions introduced in utm_0.5.0 is not intuitive for physicists. "mt" should be used for transverse mass. For defining continuous range of indices, minimum/maximum fields of cut data structure are better suited. These points can easily be fixed during the adaptation of mt and others in Xerces31 branch of UTM. For already implemented features in VHDL producer/emulator, find and replace operations of enumerations may be needed if different enumerations to be used. Other minor changes may be needed but should be trivial.
[1] https://its.cern.ch/jira/browse/CMSLITDPG-44 [2] https://gitlab.cern.ch/cms-l1t-utm/utm/merge_requests/1
GT Correlation Conditions with multiple cuts
I don't know if people are already aware of this, so I will provide the information here for completion.
In the current version of the emulation of CorrelationConditions in the GT, we support 4 types of correlation cuts:
The emulator applies these cuts in a consequtive (non-exclusive) way, one object-combination at a time. The results of the individual cuts are effectively ANDed, and in case of TRUE the object-combination at hand is stored. Process is repeated looping over all possible combinations. In case at least one object-combination stored, the condition is evaluated as PASS.
Questions I have: 1) Is our uGT fw capable of doing multiple correlation cuts at a time 2) Do we have the functionality in the TME to create xml files with corr. algos with multiple cuts.
So, if in the xml file there is a correlation condition algorithm that contains more than one correlation cut in its definition, all off the cuts will be applied and ANDed. This will probably be useful for the PAGs, an example being VBF (diJet with deltaEta>3, mjj>400).
Are PAG people already doing these tests with L1 seeds?