The goal of this twiki page is to provide information about the O2O mechanism implementation for the CSCTF. The O2O (Online To Offline) L1 emulator configuration mechanism is essential to configure the emulator on a run-by-run fashion for data/emulator comparisons and MC generation. The general framework is centrally developed and maintained, but every single CMS L1 trigger subsystem needs to provide code and support for their individual needs.

Useful Links

General knowledge:

Developing testing scripts:

  • L1O2OOperations: current L1 O2O online setup status
    • This twiki page is particularly useful because it point to scripts to be used for test the O2O mechanism
    • Section " Validation" - "Testing new keys with emulator" explains how to test the chain O2O->Emulator configuration in .cms cluster, script testEmulator.py in /!L1TriggerConfig/CSCTFConfigProducers/test is based on the example from this twiki page
  • SWGuideL1O2OTestJob: instructions for validating L1 subsystem O2O code
    • How to test whether a given object key can be read from OMDS and produce the C++ configuration objects from OMDS data.
    • The O2O python scripts in L1TriggerConfig/CSCTFConfigProducers/test are based on the example from this twiki page.

How to check the CSCTF L1 configuration in a global tag (for 3XY series):

The policy for L1 trigger configuration in Monte Carlo global tags is well described in the following email from Vasile Ghete dated 1st September 2010:

Arrow blue right Show MC Policy For G-TAG Hide MC Policy For G-TAG

Dear colleagues,

I would like to re-iterate the policy presented yesterday concerning the update of the L1 configuration 
in the global tags used for MC production and RelVals.

As you know, L1 configuration is now the same in all MC global tags (START, MC, DESIGN - for the time being), 
so we have to maintain only one set of configuration payloads, the set  used in previously in
START(UP) tags which should match the online configuration used for data taking.

For data taking, the configuration is updated in real time, via O2O, so the GR global tags 
reflects the hardware configuration  (assuming that all the relevant quantities are already in O2O).

The following update policy is proposed: whenever a system has changes online affecting performance, 
the parameters changed are in the global tag and the parameters are intended to be used as default for 
longer periods of data taking, the system responsible must ask me/Werner/Eric/Zongru for updated 
MC tags immediately after the configuration is used online.

For temporary changes, it is up to the system responsible to judge 
if they would need MC events for that configuration.

For MC large production we can then choose the most appropriate configuration from the existing payloads, 
depending on the production purpose, in consultation with system responsibles and L1 DPG.

I would like to ask the people responsible to cross-check the online configuration and to ask immediately 
for updated MC global tags if the online configuration is not consistent with the MC configuration. Please 
check the latest START g-tag for 38X (START38_V10)


and send a mail confirming the consistency or requesting an update of the payloads.

Please note: after the short period needed to cross-check the consistency online - MC configuration, 
any request to update the MC configuration to some older configuration which was not  already
included in a MC global tag will be simply ignored (except for special-purpose MC productions). 



Visit this CMS message (to reply or unsubscribe) at:

Test the O2O producers from OMDS

The step to follow are:

  • Install the release on .cms network
  • Run the test scripts

Install the release on .cms network

The instructions and the updated cvs tag (by Werner) are all at https://twiki.cern.ch/twiki/bin/view/CMS/L1O2OOperations, section "Testing new keys with emulator".

Comment: in general the tags in the twiki page won't be updated. If in doubt, please you Werner Sun (the O2O guru). Anyway for almost all your development you will need only CondFormats/L1TObjects/ and L1TriggerConfig/CSCTFConfigProducers/ and you should know their tags (at least of the latter!). Otherwise give a shot to the HEAD version smile

Run the test scripts

All the test python scripts are located in L1TriggerConfig/CSCTFConfigProducers/test/:

  • testO2O_csctf_cfg.py
  • testO2O_ptlut_cfg.py

Before running these scripts, we need to initialize the environment as reported on https://twiki.cern.ch/twiki/bin/viewauth/CMS/SWGuideL1O2OTestJob.
An alternative possible way (I do not guarantee it works) is:

  • mkdir $CMSSW_BASE/results
  • cd $CMSSW_BASE/results
  • cp $CMSSW_BASE/src/L1TriggerConfig/CSCTFConfigProducers/test/authentication.xml $CMSSW_BASE/src/L1TriggerConfig/CSCTFConfigProducers/test/setO2Oenv .
  • change the value for the password in authentication.xml. You should know where to find the passwd, otherwise you are not a L1 expert...
  • source the commands in setO2Oenv

COMMENT: the two aforementioned scripts have been produced directly using the instructions from the twiki page, https://twiki.cern.ch/twiki/bin/viewauth/CMS/SWGuideL1O2OTestJob.


For this test it is enough running the default script. If you want to test new TSC keys, just modify the line

process.L1SubsystemKeysOnline.tscKey = cms.string( 'TSC_blabla' )
with the online TSC key of your choice.


If you run it you will produce the object, but not visualize the output. This is because the Pt LUTs are 2^21 lines and I did not want to make the output too verbose and un-understandable. If you want to print out the Pt LUTs content:

1) in file L1TriggerConfig/CSCTFConfigProducers/src/L1MuCSCPtLutConfigOnlineProd.cc, please uncomment lines

// if uncommented it will generate a huge output...
//edm::LogInfo( "L1-O2O: L1MuCSCPtLutConfigOnlineProd" ) << "PtLUT is " << ptlut;
2) recompile
3) cmsRun testO2O_ptlut_cfg.py

Validate with the emulator

There are 2 python script in the L1TriggerConfig/CSCTFConfigProducers/test:
  • testEmulator.py
  • testEmulatorFromSQLite.py

In order to run the scripts on the .cms cluster you need to copy over cmsusrslc5X machine a root file. The example on how to create a file and import to the .cms cluster is in https://twiki.cern.ch/twiki/bin/view/CMS/L1O2OOperations#Testing_new_keys_with_emulator. An example of code to generate a small file of 100 events from a root file on castor is in !L1Trigger/CSCTFConfigProducer/test/copyFile.py. This script will produce a file named Raw.root if run on the lxplus or a local machine.

Keep the size of the file Raw.root small: these scripts are meant to quickly check the configuration mechanism, NOT to run the emulator validation

The script needs to be updated
This script is fed with the file Raw.root and runs the fake emulator producer. This won't test the O2O, but it is a good starting point to know how to use the emulator script.

This is a more interesting script to run in order to check the O2O mechanism. When we change the O2O code we produce a new object which is not written yet in any global tag. For that we need Vasile and Werner. The idea here is to by-pass the global tag writing and reading. We write the payload of the object in a sql file and use the content of this file instead of the global tag for the record of interest. In our case, we want to write L1MuCSCTFConfigurationRcd and L1MuCSCPtLutRcd.

0) Initialize the environment: * unix> $CMSSW_RELEASE_BASE/src/CondTools/L1Trigger/test/bootstrap.com * unix> cmsRun $CMSSW_RELEASE_BASE/src/CondTools/L1Trigger/test/init_cfg.py

This will generate a file called l1config.db which you will overwrite

1) Writing the payload

    • writeCSCTFPayload_L1MuCSCTFRcd.py. This script writes the desired L1MuCSCTF configuration in the l1config sql file.
    • writeCSCTFPayload_PtLUTRcd.py. This script writes the desired Pt LUT in the l1config sql file.

If you run the scripts sequentially you will write both payloads and you could then test both of them at the same time.

2) Before running the emulator you need to make the new payloads "visible", which means set the iov (interval of validity).

    • if yout type
       cmscond_list_iov -c sqlite_file:l1config.db -a
      you will get the list of the tags active in the sqlite file and you will see that the records for the CSCTF configuration or the Pt LUT is not printed out.

    • unix> cmsRun $CMSSW_RELEASE_BASE/src/CondTools/L1Trigger/test/L1ConfigWriteSingleIOV_cfg.py tscKey=4 objectType=L1MuCSCPtLut recordName=L1MuCSCPtLutRcd tagName=L1MuCSCPtLut outputDBConnect="sqlite_file:l1config.db"

If you relaunch the command 2.1 you will see that the PtLUT record is now visible. Repeat command 2.2 by replacing tscKey, objectType, recordName and tagName with the appropriate ones for the CSCTF configuration.

3) Finally we are ready to run the emulator. Ready to rock? Then run testEmulatorFromSQLite.py

* unix> cmsRun $CMSSW_RELEASE/src/L1TriggerConfig/CSCTFConfigProducer/test/testEmulatorFromSQLite.py

Read the global tag content via CMSSW

You have two options:

  • Using and configuring the script in L1Trigger/Configuration/test/L1GlobalTagTest_cfg.py (thanks Vasile!)
  • set a cms environment (cmsenv) and then type listoftags oracle://cms_orcoff_prod/CMS_COND_31X_GLOBALTAG THE_GLOBAL_TAG_YOU_NEED | grep L1MuCSC

Add A Core To L1Trigger/CSCTrackFinder

  • Alex Madorsky provides you with a new core dated XXXX-YY-ZZ:
    • XXXX is the year
    • YY is the month
    • ZZ is the day

  • Install the core:
          cd L1Trigger/CSCTrackFinder/src
          mkdir core_XXXX_YY_ZZ
          cd core_XXXX_YY_ZZ
          wget http://www.phys.ufl.edu/~madorsky/sp/XXXX-YY-ZZ/vpp_generated.zip
          unzip vpp_generated.zip
    • Leave only the files vpp_generated.h (cpp), vpp_generated_constructor.cpp, vpp_generated_init.h (cpp), vpp_tools.h, vpp_wrap.h (cpp), and comp_dphi_*.dat
            mkdir L1Trigger/CSCTrackFinder/data/core_XXXX_YY_ZZ
            cp L1Trigger/CSCTrackFinder/data/core_XXXX_YY_ZZ/comp_dphi_*.dat L1Trigger/CSCTrackFinder/data/core_XXXX_YY_ZZ

  • Modify L1Trigger/CSCTrackFinder/interface/CSCTFSPCoreLogic.h
    • #include <L1Trigger/CSCTrackFinder/src/core_XXXX_YY_ZZ/vpp_generated.h>
    • add class vpp_generated_XXXX_YY_ZZ
    • add vpp_generated_XXXX_YY_ZZ sp_XXXX_YY_ZZ_ in private members

  • Modify L1Trigger/CSCTrackFinder/src/CSCTFSPCoreLogic.cc
    • add vpp_generated_XXXX_YY_ZZ CSCTFSPCoreLogic::sp_XXXX_YY_ZZ_;
    • add in the "CSCTFSPCoreLogic::run" method
    • case XXXXYYZZ:
             sp_2010_10_11_.wrap ( bla, bla, bla ) 

  • Modify L1Trigger/CSCTrackFinder/src/CSCTFSectorProcessor.cc
    • insert the firmSP_Map.insert(std::pair<int,int>(dayfromthekey, XXXXYYZZ));, where dayfromthekey is the day in the DBS configuration key "SP SP dayfromthekey"
    • optional: modify the "CSCTFSectorProcessor::printDisclaimer" with new line(s) for dayfromthekey. A new core has obviously a new feature you may want to display.

  • compile:
    • cd L1Trigger/CSCTrackFinder/src/
    • scramv1 b -r -j4


Running the L1TEMU

Useful links:

The link on how to learn how to run the DQM online for L1TEMU is https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideL1DQM#L1_Trigger_emulator_DQM_based_on:

  • Checkout the packages as recommended
  • the file to run is DQM/L1TMonitor/test/l1temulator_dqm_sourceclient-file_cfg.py
  • the poolsource is defined in DQM/L1TMonitor/python/inputsource_file_cfi.py

Example of a macro to analyze output of CSCTF L1TEMU module here:

  • cp l1temu.C.txt l1temu.C
  • Change inside the macro the file name and the path to the CSCTFexpert folder accordingly to your run analyzed
  • root -l l1temu.C++
-- GianPieroDiGiovanni - 22-Sep-2010
Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt l1temu.C.txt r1 manage 3.0 K 2011-04-19 - 13:31 GianPieroDiGiovanni  
Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r20 - 2012-08-22 - GianPieroDiGiovanni
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback