Josh McFayden

Setting up release from MR in r21

mkdir testdir
cd testdir
mkdir source build run
cd build
acmSetup AthGeneration,21.6,latest
acm sparse_clone_project athena zmarshal/athena.git 21.6_MGC_Update
acm add_pkg athena/Generators/MadGraphControl
acm compile

To-do table test


MC production notes

Getting started with evgen

See this TWiki page for a very general overview of running generators in ATLAS: And this one which is a bit more specific to MC15:

The basic idea is that you have some python jobOptions that load and run your MC generator of choice. You run this in Athena by doing

asetup <some release>,here <arguments>

Where the generate transform ( is essentially a bit of python that creates a simplified version of a more complicated Athena command/jobOptions that has nice command line arguments. should be whatever the most recent release that MC production is using, but this information can be hard to find and for now I would suggest you use


Then the main thing you will use to generate events is MadGraphControl. This is a package for running MadGraph5_aMC@NLO in Athena via some python steering. You can take a look at this TWiki page to get an idea of how this works and some simple examples:

Job submission script

Script is (please remove ".text" suffix).

Usage is essentially:

./ <generation mode [-f:on-the-fly,-g: gridpack mode]> <run mode [-b:build tarball,-t:run from tarball> -i <DSID> -c <CoM energy> -a <athena release> -j <jobOptions> -n <number of jobs> [-p <gripack location> -s <site(s)>]

  • A couple of examples:
    • On-the-fly:
./ -f -b -o -i "999999" -c 7000 -a,here -j -n "200"
./ -f -t -o -i "999999" -c 7000 -a,here -j -n "200"
(the first line builds the panda tarball, the second submits the jobs - this is useful if you want to send e.g. several DSIDs because you don't have to remake the tarball each time)

    • From gridpack:
./ -g -b -o -i "999999" -c 7000 -a,here -j -n "200" -p <gridpack location>
./ -g -t -o -i "999999" -c 7000 -a,here -j -n "200" -p <gridpack location> -s ANALY_CERN_SLC6,ANALY_BNL_LONG
(only send jobs to CERN and BNL) I suggest you start first with running some of the examples on the MG5_aMC@NLO TWiki page above first as that's a bit simpler.

MC production coordinator notes


  • Physics Coord (Monday 15:00)
  • ADC Weekly (Tuesday 14:45)
  • Simulation Steering (Tuesday 16:00)
  • MC Production (Wednesday 10:00)
  • PMG subgroup+software+production (Monday, 13:00)
  • ProdSys2 ("coffee" meetings) (Tues & Thurs 9:00) indico

Useful webpages


tarball dir



  • "pts add mcfayden zp:mcgen" should work...
  • "pts membership `whoami`" it will at least tell you what you have permissions for...
  • "fs sa . mcfayden rlidwka" also?

SUSY MC contact notes


  • Start
    • Fill in BIG spreadsheet as far as possible
    • Assign DSIDs
    • Request spreadsheet and jobOptions tarball
    • Check jobOptions (use scripts)

  • Follow JIRA workflow:
    • Start at "To do" --> ask for SUSY subgroup approval - "@A and @B, has this request been discussed, and are you happy with it?"
    • When approved click "Initial sign-off" --> "In progress"
    • "Create" issue with MC prod people (see below)
    • Add spreadsheet to SUSY MC spreadsheets page here
    • "In progress" --> Get jobOptions and spreadsheet etc. click "Inputs/jOs" ...
    • ... this takes us to --> "Prepare"
    • "Prepare" --> Ask for validation --> "Validation" (validation optional to an extent)
    • "Validation" --> if validation ok --> "Request ready"
    • "Request ready" --> ask SUSY group convenors for approval
        • Here add in comments "We now have MC12JobOptions-XX-YY-ZZ for this, so it's up to [~jboyd] and [~onofrio] to approve this request for N {type} events in M datasets at priority Y" * Now click "Group sign-off" --> "In review" * "In review" --> ask Physics Coordination for approval:
      • Use standard template (below) - information can be taken from spreadsheet.
Subject: SUSY <MCCampaign> <CoMEnergy> Request: <description>

Hi Andreas,

The SUSY group would like to request ...<brief description (JIRA title)>... samples with <Generator(s)> at <CoMEnergy>. These samples are ...<brief justification> . The full request is for <N> <type> events in <X> datasets at priority <Y>.

The JIRA thread is here: ...

Technical details:
- The DSIDs are ...
- The spreadsheet for the request is at ...
- <type> priority <Y>
- <jobOptions tag/info>
- DESDs to be kept
      • Include in cc: SUSY convenors, subgroup convenors, atlas_csc_mcprodman
    • Once approved, click "PC approved" --> "Approved"
    • "Approved" - now marked as done in JIRA

  • Request to MC prod people
    • In JIRA "create issue"
      • Project: default
      • Issue type: Bug
      • Summary: description and DSIDs
      • Priority: Ignore this unless it is very urgent
      • Components: MCJobOptions
      • Labels: SUSY, MC12JobOptions
      • Attach tarball with jOs - needs format so that it could slot straight into MC12JobOptions
      • Description: "The SUSY group would like to request the attached files for inclusion in the next tag of MC12JobOptions. They implement There are a few dummy job options files, one modified control file, a couple of slha files, .. Please let me know if you spot any problems."

  • If there are input files
    • Edit evgeninputfiles.csv
    • Tag updated version

  • Check if jobs are running - if not contact requester

BIG Spreadsheet columns/colours

  • DS start-DS end, N samples
  • Color code: white - just came in, yellow - I need to do something, light green - jobs not submitted or still running, purple - problem with initial submission and not yet resolved, dark green - all done
  • SUSY: SUSY convenors approved?
  • ATLAS: ATLAS approved?
  • Prio: Priority in JIRA - colour RED if prio=high (3=minor,5=major,...)
  • PP: Production priority (from request spreadsheet)
  • nEe: N events EvGen only
  • nEG: N events FullSim only
  • nEF: N events FastSim only
  • SG: Which SUSY subgroup group


JIRA SUSY summary BIG spreadsheet
MC spreadsheets - Google Drive Example request spreadsheet
SUSYMcRequestProcedure TWiki
Release status
AtlasMcProductionMC12 TWiki
AtlasProductionGroupMC12a TWiki
PreparingLesHouchesEven TWiki
SUSYEvGenValidation TWiki
MCProdJira TWiki
To register inputs/integration grids/config files



  • For an Atlfast-II job the black magic of Atlfast-II happens in the reco step in this case (sim just does the ID, the calorimeter simulation actually doesn't happen until that second step) so the "recon" job gets given a second "_aXYZ" tag rather than a "_rABC" tag. E.g. e2880_a188_a171
  • For the spreadsheets the following convention should be followed - for the dummy tags e1111_a2222_a3333_r4444:
- e1111 goes in the "Evgen" column
- a2222 goes in the "Simul" column
- a3333 goes in the "Atlfast" column (even though it's a reco tag)
- r4444 goes in the "Atlf Merge" column (even though it's a reco merge tag)


The usual procedure is if it is a bugfix and the old samples are buggy (read: will not be used by analyses) you can go with the same DSID and rename if necessary (Josh, make sure during the request that you ask them to mark the old ones as obsolete and schedule them for deletion). If those old samples will be used by any analyses, then go with new DSIDs.

If it's a bug fix and it's small (20k-100k events) you don't strictly have to go through PC; you can directly iterate with the production team. If it's more than about 100k then it's good practice to make sure PC is aware.

Replacing existing jOs:

Always do a diff of new and old to make sure changes make sense


Need to request a new tag. Try to check how much has changed between new version and previous version via diff and/or ChangeLog if it's not too much then you probably Zach to) and request a new pcache with new tag. Add this new pcache to the release column of request spreadsheet.

Sherpa integration grids

These are always required even for processes that are "quick" to generate.

UEEE3 in 13 TeV

We have a proper energy extrapolation tune (as opposed to a tune, with adjusted parameters for specific CM energies) for 13 TeV with UEEE4(5) so UEEE3 is not an option for 13 TeV jobs (it is for 7,8,14 TeV).


asetup,MCProd,64,slc5,here... tar czf input.tar.gz Process/ Results.db



Direct stop 0-lepton 2012 8TeV data


  • Working from SUSYTools-00-01-03
  • Using p1032(1033) tags of NTUP_SUSY


Code can be found here:

Main changes wrt 2011 object definitions


  • Now using AntiKt4LCTopo jets rather than AntiKt4TopoNewEM
  • No calibration required anymore


  • No new recommendations afaik


  • electron quality flags wrong in D3PDs (not sure which tags) -> define using functions, using:
       #include "egammaAnalysisUtils/IsEMPlusPlusDefs.h"
       #include "egammaEvent/egammaPIDdefs.h"


  • Don't appear to have changed...


  • jet+MET:
    • EF_j80_a4tchad_xe100_tclcw_loose
    • EF_j170_a4tchad_EFxe80_tclcw
  • single electron:
    • EF_e24vh_medium1_EFxe35_tclcw
  • single muon:
    • EF_mu24_j65_a4tchad_EFxe40_tclcw

Initialisation of most tools now slightly different. See SUSYObjDef.cxx .


Emulation code for EF jet triggers in 2011 using D3PDs. This tool should be quite versatile. Initially it was developed for emulation of EF_*a4tc* jet triggers from mc10a has only EF_*a4* type branches in the menu. From the inputted EF trigger name string it works out the type of trigger and thresholds to be applied. The L2 decision is required as an input.

  • Emulates different jet algorithms, a4, a4tc, a10tc... etc.
  • Only requires L2 decision and trigger name as an input

Basic Instructions

Setting up

You need to compile the .cxx file with the rest of your code (exactly how you do this depends on how you run on the D3PDs...). For example if you used a MakeClass in root you would want to do something like:
gROOT->ProcessLine(".L trigEmulator.cxx+");

before you start calling the function "Loop()"

Then in your main analysis file include the header:

#include "trigEmulator.h"
and in your main analysis function but outside the event loop you should do something like this:
trigEmulator::trigEmulator myEFTrig;   

Feeding D3PD branches

Then inside the event loop you need to give the emulator the branches it needs something like this (again it depends on your setup how you call the branches etc.):


Then again inside the event loop, you get the emulated EF decision by passing the L2 decision and the string of the EF trigger you want like this:
bool testBit_EF_j75_a4tc_EFFS = myEFTrig.isPassed(L2_j70,"EF_j75_a4tc_EFFS");        


  • steer.C: Steering file for MakeClass example

Major updates:
-- JoshMcFayden - 16-May-2011

%RESPONSIBLE% Main.unknown
%REVIEW% Never reviewed

Topic attachments
I Attachment History Action SizeSorted ascending Date Who Comment
C source code filec steer.C r1 manage 0.7 K 2011-05-16 - 20:45 UnknownUser Steering file for MakeClass example
Header fileh trigEmulator.h r1 manage 1.2 K 2011-05-16 - 20:43 UnknownUser trigEmulator class header file
Unknown file formatcxx trigEmulator.cxx r1 manage 6.0 K 2011-05-16 - 20:42 UnknownUser trigEmulator class C++ file
C source code filec testClass.C r1 manage 8.5 K 2011-05-16 - 20:46 UnknownUser MakeClass .C file
Texttext r1 manage 9.3 K 2015-04-30 - 15:00 JoshMcFayden Pathena evgen job submission script
Header fileh testClass.h r1 manage 556.7 K 2011-05-16 - 20:47 UnknownUser MakeClass header file

This topic: Sandbox > JoshMcFayden
Topic revision: r38 - 2018-11-06 - JoshMcFayden
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback