search

cms-l1t-offline / cmssw

CMS Offline Software
cms-sw.github.io/cmssw
Apache License 2.0
17 stars 27 forks source link

GT: Multiple correlations on the same combination in CorrelationCondition #493

Open rekovic opened 7 years ago

rekovic commented 7 years ago

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:

  1. dEta
  2. dPhi
  3. dR
  4. Mass

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?

tmatsush commented 7 years ago

see page 3 of the following slides; https://indico.cern.ch/event/623817/contributions/2520240/attachments/1429860/2195815/20170317.pdf

johanneswittmann commented 7 years ago

Hi Vladimir, to answer your questions:

  1. Yes, the uGT fw can combine all of the 4 correlation cut types.

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

tmatsush commented 7 years ago

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.

johanneswittmann commented 7 years ago

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.

tmatsush commented 7 years ago

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.

johanneswittmann commented 7 years ago

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.

rekovic commented 7 years ago

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

johanneswittmann commented 7 years ago

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

tmatsush commented 7 years ago

@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