JETriggerStudies

From LHEP Wiki
Jump to navigation Jump to search

SVN tag committing


To the trunk

  • Checkout the package I want to update: >pkgco.py (or: >cmt co -r) <package>
  • Make my changes
  • Control all files I have modified: >svn status (there is an M next to every file modified)
>svn diff (for more details: every line in every file modified is visible)
  • Switch to the trunk: >svn switch $SVNROOT/Trigger/TrigHypothesis/TrigJetHypo/trunk
    • If you get any conflicts resolve them pressing 'e' when it prompts you, edit, then save, then mark resolved either by pressing 'r' when you're prompted or by doing an "svn resolved my/resolved/thing.h" (make sure the final code is as you expect).
  • Commit: >svn ci -m "message"
  • cp the working package to the tag directory (from your local TrigJetHypo directory): >svn cp . $SVNROOT/Trigger/TrigHypothesis/TrigJetHypo/tags/TrigJetHypo-00-02-20 -m "message"
    • where 00-02-20 is the new tag


To the branch

  • The same as for the trunk but:
    • to check out the package: >pkgo.py (or: >cmt co -r) TrigJetHypo-00-02-13-branch Trigger/TrigHypothesis/TrigJetHypo
    • to switch to the branch: >svn switch $SVNROOT/Trigger/TrigHypothesis/TrigJetHypo/branches/TrigJetHypo-00-02-13-branch
    • to cp the working package to the tag directory (from your local TrigJetHypo directory): >svn cp . $SVNROOT/Trigger/TrigHypothesis/TrigJetHypo/tags/TrigJetHypo-00-02-13-05 -m "message"
      • where 00-02-13-05 is the new tag


L2TrigJetHypo


Setup Athena

The L2 trigger is rerun using athenaMT. This takes as input a RAW file and produces as output a new RAW file. To run athenaMT you must first setup an AtlasCAFHLT or AtlasP1HLT release.


Setup the Hypo

  • >cd $TestArea
  • checkout TrigJetHypo: >pkgco.py TrigJetHypo
  • (show which package is: >pkgco.py -s TrigJetHypo)
  • >cd Trigger/TrigHypothesis/TrigJetHypo/cmt
  • build and compile:
  • >cmt config
  • >source setup.sh
  • >gmake


Modify the Scripts

  • >cd Trigger/TrigHypothesis/TrigJetHypo/src
  • >cp TrigL2MultiJetHypo.cxx ./MyHypo.cxx
    • replace all TrigL2MultiJetHypo labels with MyHypo


  • >cd Trigger/TrigHypothesis/TrigJetHypo
  • >cp TrigL2MultiJetHypo.h ./MyHypo.h
    • replace all TrigL2MultiJetHypo labels with MyHypo


  • >cd Trigger/TrigHypothesis/TrigJetHypo/src/components
    • edit TrigJetHypo_entries.cxx adding MyHypo


Setup the Hypo Configuration

  • >cd Trigger/TrigHypothesis/TrigJetHypo/python
    • edit TrigJetHypoConfig.py adding:
  • from TrigJetHypo.TrigJetHypoConf import MyHypo
  • the same classes which appear for L2MultiJetHypo modified for MyHypo


  • IMPORTANT RECOMPILE! (see above)


Declare a Trigger Chain with new Hypo

  • >cd $TestArea
  • checkout (the last version): >pkgco.py TriggerMenuPython-00-19-40
  • go to the directory appeared: >cd Trigger/TriggerCommon/TriggerMenuPython/python
  • open JetDef.py and edit adding:
  • from TrigJetHypo.TrigJetHypoConf import MyHypo
  • (in the dictionary) hypos.update(dict([ ('l2_MyHypo', FullScanMyHypo('L2MyHypo'))]))
  • replace in one of the L1.5 Chains (for instance NoCut_a4TT_L15FS_L14J10_NoEF) the l2_MultiJetHypo with l2_MyHypo label


  • >cd Trigger/TriggerCommon/TriggerMenuPython/cmt
  • compile:
  • >cmt config
  • >source setup.sh
  • >gmake


Run Athena


  • to read the .log file online: >less MyLog.log
    'Shift' 'F'


Rerunning the EF

In order to have a sensible output file it's also necessary to rerun the EF. This is acheived in a similar way to L2 except this time the athenaPT program is used to reprocess the output produced by athenaMT:

  • athenaPT -f outputMT-1._0101.data -o outputPT CaloTestFull.py
    • (NOTE: put the last version of outputMT .data file)
  • an outputPT .data file will be produced


Reconstruction

In order to properly investigate the contents of our new RAW file one should rerun the reconstruction. To produce an AOD and an ESD from the outputPT file, first setup an AtlasProduction release:

  • mkdir 17.0.4.5
  • asetup AtlasProduction,17.0.4.5,here,setup
  • cd $TestArea
  • prepare a preInclude file to tell the reconstruction about your new menu: TrigConf.py (see https://twiki.cern.ch/twiki/bin/view/Sandbox/MatthewTamsettSandbox)
  • copy the HLTconfig_Physics_pp_v3_16.1.3.16.3.xml file from the 16.1.3.16.3 directory in this directory
    • (NOTE: .xml file changes if the JobOptions menu is changed)


Ready for the Reconstruction:

  • Reco_trf.py --ignoreerrors=True autoConfiguration=everything preInclude=TrigConf.py inputBSFile=(PATH)/outputPT-1._0001.data outputESDFile=my_ESD.pool.root outputAODFile=my_AOD.pool.root
    • (NOTE: put the last version of outputPT .data file)


  • two output files will be produced:
  • my_ESD.pool.root
  • my_AOD.pool.root
  • check the two root files:
  • checkFile.py my_AOD.pool.root
  • checkTrigger.py my_AOD.pool.root
    • (NOTE: One important thing to note is that the reconstruction will fail if an AOD/ESD file exists with the same name you specify. So make sure you choose a unique name)


DPD Making

To reconstruct DPDs from an AOD simply setup an appropriate AtlasPhysics release:

  • mkdir 16.6.6.5.2
  • asetup AtlasPhysics,16.6.6.5.2,here,setup
  • cd $TestArea
  • Reco_trf.py --ignoreerrors=True inputAODFile=my_AOD.pool.root maxEvents=-1 outputNTUP_JETMETFile=my_DPD.root autoConfiguration=everything
  • my_DPD.root will be produced


Aim: characterize L1_JE, L2_je and EF_je/hT to define a JE menu for 2012

Menu proposal expected by November 2011 Understand on which variables depends the JE Trigger Efficiency

To do list (general)

  • Offline: use jet Et when using EM calibration, use jet pT when using hadronic calibration (M. Begel suggestion on 31 Aug 2010)
  • Use L1_J thresholds and corresponding weights as in 2011 data (31 Aug 2011)
  • Use online information instead of simulation macro (31 Aug 2011)
  • Regarding pileup studies: consider JVF (example for tau trigger slide 4, etc and 16, etc in Oct talk [1] 12 Oct 2012)
  • Study 'b-jets' separately (using muon distance with respect to closer jet) (M. Begel suggestion on 31 Aug 2011)
  • Jet cleaning:
    • Use loose when using muon trigger as control trigger (M. Begel suggestion on 31 Aug 2011)
    • Use timming cuts when using jet trigger as control trigger (M. Begel suggestion on 31 Aug 2011)

Done items

  • Change 70GeV threshold to be 75GeV (M. Begel suggestion on 31 Aug 2011)

To do list (detailed)

Explore the use of 'number of tracks per vertex' to understand pileup (Oct 5 2010)

In our aim to understand the effects of pileup in HT we are considering exploring the following:

  • Check the number of tracks associated to each vertex
  • Identify the vertex with the higher number of tracks (call it VHNT
  • Study if the jets of higher pt are associated to the vertex with higher number of tracks

If this would be the case (we might need to also consider the vertex with 'the second highest number of tracks' and so on)

  • Study HT value for jets associated to the vertex with the higher number of tracks
  • Study HT for jets associated to 'all the other vertext but VHNT'
  • Study HT for all jets
  • Study correlations between all three HT values above
  • Do the study for different numbers of primary vertex separately

Useful info

L1 jet thresholds and weights

  • Andreas Battaglia's macro to simulate JE

https://twiki.cern.ch/twiki/bin/view/AtlasProtected/SusyTrigSimD3PD

  • Alan Watson's email on Sept 1st

Hi Teresa,


Marco is working in the L1_JE trigger characterization and i don't know enough to help him. Could you give us a hand or point us who to ask?

We need to know:

-> The reason to use weights at L1_JE a) i thought it was because it was not possible to add the Et of the jets, because this info was not available, and, only the number of L1_JX thresholds that had satisfied the trigger (for each of the 8 different X) is available. Is this correct? Michael mentioned yesterday that maybe weights are not needed anymore because maybe its use had to do with the fact that we had RoIs of different sizes. But he said that maybe a) was the reason.

-> Have the weights been changed during 2011 when the L1_J thresholds were changed?

The reason is as you say: we only have the threshold multiplicities available. This is something that can change in the Phase 1 upgrade, when we'll be able to send more data over the backplanes, but not before.

Weights are computed from the jet thresholds in the trigger menu, so change whenever the L1_J thresholds change.


-> is the JE value computed by L1 and used to take the decision stored somewhere? So that Marco can retrieve it and use it for his studies or the only possibility is to retrieve L1_J threshold and from there simulate the JE trigger behaviour with the weights and so on....

Unfortunately it is not read out.

If you are able to load the correct L1 menu into your job you can use Trigger/TrigT1/TrigT1CaloTools/L1JetEtTools to calculate the value the hardware would have produced. The function

virtual unsigned int jetEtSum(const std::vector<Jet_ROI>& rois);

will accept a std::vector of the Jet_ROI objects used in offline analysis (as obtained from LVL1_ROI) and return the jetEtSum from these. The scale will be the actual L1 scale (not multiplied by 1000 to look like offline units). It obtains the weights from the TrigConfigSvc or Lvl1ConfigSvc. This will replicate exactly what the firmware would do, provided the menu contains the correct weights.

There's also another call which allows you to supply a vector of threshold multiplicities and another of weight values, if you feel like doing everything by hand, but the one above is probably simplest.

cheers, Alan

  • Steve Hillier email on Sept 1st

Hello, a few answers

-> Yes, your explanation is quite right. At the point in the hardware where the JE triggers are formed, the actual energy sums in the Jets is no longer available, only the number of thresholds passed. So we can only make a very rough estimation based on those, rather than summing the individual jets. It is quite likely that we will be able to do a better job than this in the very first (Phase-0) upgrade, but that's not until 2014/2015, so not for next year.

->The weights change with a change in the jet thresholds. I think this is an automatic feature of the menugeneration, so should always work. However with each new Level-1 menu, I do tend to check that the weights look right - there's been no problem yet.

-> No, I'm afraid we don't record the actual value, it's perhaps something we should change, it's one of the few intermediate values that we don't record. However, I'm sure Alan has a tool for re-creating it, and we know that this is an accurate tool since we check on an event by event basis that the simulation gets the same result as the hardware.

Good luck with the analysis. I'm afraid JE is not the most well behaved trigger! And the accuracy of the JE trigger is not uppermost on people's minds when they set the Jet thresholds. Cheers, Steve

Retrieved from "https://wiki.lhep.unibe.ch/index.php?title=JETriggerStudies&oldid=259"