Skip to content
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

Ensure correct emulation for historical events #2

Closed
3 tasks done
jiafulow opened this issue Mar 20, 2020 · 3 comments
Closed
3 tasks done

Ensure correct emulation for historical events #2

jiafulow opened this issue Mar 20, 2020 · 3 comments
Assignees
Labels

Comments

@jiafulow
Copy link
Owner

jiafulow commented Mar 20, 2020

Some issues have been reported when using the EMTF emulator from the latest CMSSW release to run on old collision & MC simulation data, due to conflicts among global tags/O2O/python config. The emulator needs to ensure that (global tag, O2O, era, python config, CMSSW release)-combination gives consistent results.

Specific tasks:

  • Implement EMTFSetup class used to carry "global" objects (such as VersionControl).
  • Implement VersionControl class (detailed below).
  • Also clean up the assert statements.
@jiafulow
Copy link
Owner Author

jiafulow commented Mar 20, 2020

class VersionControl

  • The EMTF emulator is configured by parameters and assets. By parameters, I refer to configuration parameters, such as firmware version, era, etc -- all the things that are specified in the "L1TMuonEndCapTrackProducer" module + all the things that are provided by the "L1TMuonEndCapParamsRcd" event setup module. By assets, I refer to (often large) data files, such as all the things that are stored under the "L1Trigger/L1TMuon/data" directory + all the things that are provided by the "L1TMuonEndCapForestRcd" event setup module (currently the BDT xml files, but there could be more in the future).

  • For collision data, both the parameters and assets should be fully controlled by the O2O. Currently, this is done by configuring the emulator logic based on the firmware version [1] (which is provided by the L1TMuonEndCapParamsRcd, which depends on the GlobalTag). Future modifications to the EMTF algorithm will require adding more lines to [1].

    • However, due to incorrect implementation, certain parameters are not being configured in [1], but in [2].
    • Fix proposal: create a new class (tentatively "VersionControl") that configure ALL the parameters in that class.
  • For MC simulation, both the parameters and assets should be fully controlled by the GlobalTag. Currently, this is not the case, as the parameters and assets are configured by a mix of the python cfi file (simEmtfDigis_cfi.py) and the L1TMuonEndCapForestRcd (which depends on the GlobalTag). It should be changed to preserve data-MC symmetry in how the emulator runs. Note: for collision data, the firmware version comes from the GlobalTag, and it is set by O2O automatically. For MC simulation, we would need to manually update the GlobalTag. After the CondDB is updated, the changes need to be manually propagated through CMSSW as well ( making sure "auto:run2_mc" GT still works correctly).

    • Fix proposal: once the new class (tentatively "VersionControl") is implemented, this should be trivial.
    • Currently, it is expected that we'd need the corresponding GTs for 3 different eras: Run2_2016, Run2_2017, and Run2_2018. It is also expected that another era: Run3_2021 would need to be added in the future.
  • With the proposed fix, there should be no need to expose many of the configuration parameters in the python cfi file to the users. A lot of them should be removed to avoid confusion in the future, leaving simply the era and the InputTags. [3] (probably also the CSCInputBXShift and the likes which are technically not part of EMTF, but from "upstream").

  • It is still necessary to make sure that the O2O functions correctly, and that the GTs / payloads are set up correctly.

    • I think there should be someone (yes, a real human) who takes care of this for the EMTF emulator (especially in keeping track of the various GTs). It could be someone from the EMTF group, or it could be someone from L1T who can take care of not just EMTF, but also others (GMT, BMTF, OMTF, etc).
  • One concern is that the emulator is also used for future developments (where firmware hasn't even been written). This is particularly important for EMTF, as it is in continuous upgrade (as GEM, ME0, iRPC are being added in the future), so implementations will likely happen in the software before the firmware. If we were to use GTs to do this, we would have to come up with a random future firmware version number to be set in the GTs, which sounds like an awkward solution.

[1] https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TMuonEndCap/src/SectorProcessor.cc#L133
[2] https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TMuonEndCap/src/TrackFinder.cc#L27
[3] https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TMuonEndCap/python/simEmtfDigis_cfi.py

@jiafulow
Copy link
Owner Author

UPDATE 04/21

  • The configuration parameter "FWConfig" will be kept. When enabled, all the configuration parameters and assets should be fully controlled by the firmware version as provided by the GlobalTag. In the case of collision data, the EMTF emulator should match very closely to the EMTF unpacker.

    • This is the behavior as described above. It should work for both collision data and MC simulation.
  • When "FWConfig" is disabled, the configuration parameters should be controlled by the global era parameter. To be clear, the firmware version as provided by the GlobalTag is ignored in this case. BUT the assets are controlled by the GlobalTag (e.g. the BDT trees). The user is responsible for providing the matching GlobalTag.

    • When there is a conflict between the global era and the GlobalTag, the user should receive an error message.
    • The ability to control the behavior without the firmware version allows us to do future developments (where firmware hasn't even been written).

@jiafulow jiafulow self-assigned this Apr 21, 2020
@jiafulow
Copy link
Owner Author

Submitted PR: cms-sw#29767

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant