Private MC sample generation

Local MC generation setup

In CMS, the SM processes are generated and simulated centrally, and we don't have to worry about them. But for a specific BSM search, a physicist has to take care of the BSM samples themselves, if they are not being handled already. For this section, I am using vector-like leptons as a reference BSM signal arXiv:1510.03556. First, we need to integrate this new physics model to the existing standard model in an event generator like MadGraph. Typically, theorists share their BSM model in the Universal FeynRules Output (UFO) format, which contain automatized matrix-element generators. These files contain python modules which can be easily included as an extension to MadGraph. This allows us to play with the new particles and the Feynman rules associated with them. I have taken the latest VLL UFO file from the repository: github.com/prudhvibhattiprolu.

This is the order of installation for this setup.

1. Setting up MadGraph along with the BSM models.
2. Building HepMC3.
3. Installing and configuring pythia for hadronization.
4. Building Delphes for detector simulation.

Here are some important packages required before installation. I am mentioning the versions that I have in my setup, but any recent versions should also work fine. I recommend using conda to install everything. It's important that ROOT is build with the same Python version that is used here. For detailed instructions on how to handle Python environments and install ROOT properly, visit here.

I would also recommend to keep all of these MC-generation tools inside the same directory. For me, the working directory is /home/phazarik/mcgeneration.

Setting up MadGraph, including the BSM models

MadGraph can be downloaded from the official website. Building is not needed. The binary file is available at mg5amcnlo/bin/mg5_aMC. I have given the full path to MadGraph in my .bashrc file as follows.

alias mg5="/home/phazarik/mcgeneration/mg5amcnlo/bin/mg5_aMC"

If you are not importing any BSM model, MadGraph setup is done. In case of any BSM model (like VLL in my case), the BSM models are unpacked into the MadGraph directory as follows.

                /home/phazarik/mcgeneration/mg5amcnlo/models/VLLS_NLO
                /home/phazarik/mcgeneration/mg5amcnlo/models/VLLD_NLO
              

These model files in my example are compatible with MadGraph version v2 that was built on python2, but should also work with the latest MadGraph v3 that uses python3. In order to use MadGraph v3, these model files are made compatible with python3, and then imported into MadGraph as follows.

                shell>> mg5 #Takes me into MadGraph interface.
                MG5_aMC> set auto_convert_model T #For compatibility with python3. 
                MG5_aMC> import model VLLD_NLO
              

If the following outputs pop-up successfully, then the setup is ready.

                INFO: Change particles name to pass to MG5 convention 

                the definition of 'j' and 'p' to 5 flavour scheme. 

                definitions of multiparticles l+ / l- / vl / vl~ unchanged 

                multiparticle all = g ghg ghg~ u c d s b u~ c~ d~ s~ b~ a gha gha~ ve vm vt e- mu- ta- ve~ vm~ vt~ e+ mu+ ta+ t t~ z w+ ghz ghwp ghwm h w- ghz~
                ghwp~ ghwm~ taup nup taup~ nup~ 

                INFO: Change particles name to pass to MG5 convention 

                definitions of multiparticles p / j / l+ / l- / vl / vl~ unchanged 

                multiparticle all = g ghg ghg~ u c d s b u~ c~ d~ s~ b~ a gha gha~ ve vm vt e- mu- ta- ve~ vm~ vt~ e+ mu+ ta+ t t~ z w+ ghz ghwp ghwm h w- ghz~
                ghwp~ ghwm~ taup nup taup~ nup~
              

Setting up HepMC3

HepMC is widely used for exchanging event information between event generators and detector simulation tools. For this exercise, HepMC3 can be downloaded from GitLab. Some usage instructions are available here.

HepMC3 can be brought from GitLab and built as follows.

                git clone https://gitlab.cern.ch/hepmc/HepMC3.git # This will create a source directory called 'HepMC3'.
                mkdir hepmc3_build  hepmc3_install                # This will create two directories where hepmc3 is built and installed.
                cd hepmc3_build                                   # This is where building hepmc3 happens.
                cmake -DCMAKE_INSTALL_PREFIX=../hepmc3_install -Dmomentum:STRING=GEV -Dlength:STRING=MM ../HepMC3
                make                                              # This requires the C++ compilers (as checked by the previous command), and takes some time.
                make install                                      # This will transfer files to the install directory.
              

Setting up PYTHIA

PYTHIA is a program for simulating particle interactions as well as hadronization. It can be downloaded from the official website. Installation instructions are provided there. The following steps are used to install pythia with HepMC3 configuration. Make sure to give the full path to HepMC3 during configuration. I am using version 8.312, but these instructions are valid for all versions.

                wget https://www.pythia.org/download/pythia83/pythia8312.tgz  # Downloading pythia.
                tar xvfz pythia8312.tgz                                       # Unzipping the tarball.
                cd pythia8312
              

In the configuration, I am including the HepMC3 library. For this, I need to put the full path to HepMC3 along with the ./configure command as follows.

                ./configure --with-hepmc3=/home/phazarik/mcgeneration/hepmc3_install
 
                # Alternative build commands:
                #./configure --with-hepmc3=/home/phazarik/mcgeneration/hepmc3_install \
                #            --with-python-include=/home/phazarik/miniconda3_backup_2024_10_09/envs/analysis/include/python3.10 \
                #            --with-python-bin=/home/phazarik/miniconda3_backup_2024_10_09/envs/analysis/bin
                # ./configure
                # ./configure --with-python

                #If everything goes right, the following report should pop up.
                #---------------------------------------------------------------------
                #|                    PYTHIA Configuration Summary                   |
                #---------------------------------------------------------------------
                #  Architecture                = LINUX
                #  C++ compiler     CXX        = g++
                #  C++ dynamic tags CXX_DTAGS  = -Wl,--disable-new-dtags
                #  C++ flags        CXX_COMMON = -O2 -std=c++11 -pedantic -W -Wall -Wshadow -fPIC -pthread
                #  C++ shared flag  CXX_SHARED = -shared
                #  Further options             =

                #The following optional external packages will be used:
                #+ HEPMC3 (-I/home/phazarik/mcgeneration/hepmc3_install/include)

                make clean                       # Removes temporary files from previous attempts, if any.
                make                             # This takes a couple of minutes.
              

Hadronization happens in the pythiaXXXX/examples directory. That's why I have built pythia in my work-area for my convenience. But it can also be kept along with the other tools and export the output files to work-area for the next steps. Anyway, once pythia is build, I added the following paths to my .bashrc file, which is needed for C++ compilation of the hadronizer codes.

                export PYTHIA8=/mnt/d/work/temp/mcgeneration/pythia8312
                export PYTHIA8DATA=$PYTHIA8/share/Pythia8/xmldoc
                export PATH=$PYTHIA8/bin:$PATH
                export LD_LIBRARY_PATH=$PYTHIA8/lib:$LD_LIBRARY_PATH
              

If you are a big fan of Python ... [optional]

In some of the examples, I have also seen PYTHIA used in a python based interface. For this, one can easily install PYTHIA and HepMC3 using conda-forge. But this is not important for the toy example that I have shared in the next section. For a new user, I would not recommend this, because managing multiple versions of tools is messy.

                conda install -c conda-forge pythia8        # not important
                conda install -c conda-forge hepmc3         # not important
              

I also found a nice YouTube video on this Python based PYTHIA interface, which is a part of an HSF workshop. This video broadly covers the basics of a lot of things that can be done with PYTHIA, starting from event generation.

Setting up Delphes

Delphes is a fast simulation framework for high-energy physics detectors. The Delphes outputs are equivalent to NanoAOD, but the information is structured differently in the ROOT files. It can be downloaded from the GitHub repository. Installation instructions are available there as well. Building delphes is pretty straight forward.

                git clone https://github.com/delphes/delphes.git
                cd delphes
                make             # This takes a couple of minutes
              

Wrapping up ... [optional]

In some examples, PYTHIA, HEPMC3 etc. can be used from the MadGraph interface itself (I'm exploring it, not an expert yet). For this, paths to PYTHIA and Delples should be included in MadGraph configuration. This has to be done once. I also added my fastjet setup, in case I need it later.

                set pythia8_path /home/phazarik/mcgeneration/pythia8312
                set delphes_path /home/phazarik/mcgeneration/delphes
                set fastjet /home/phazarik/fastjet-3.4.2/bin/fastjet-config          #optional
              

These paths are needed only when the hadronization etc is done inside MadGraph itself, by importing these modules. But in the toy example, I am doing each step of the sample generation individually. These paths can also be added manually by editing the input/mg5_configuration.txt file in the MadGraph directory. Also, MadGraph may ask for something called lhapdf, which is a standard tool for evaluating parton distribution functions (PDFs). This can be installed using conda as follows.

                conda install -c conda-forge lhapdf
              

After these installations, following are the list of MC-generation tools I have in my setup.

↑ back to top

Gridpack production in lxplus

Previous sections describe how to generate MC completely outside CMSSW framework, using delphes to approximate detector simulation. This section focuses on generating gridpacks, which are required to produce MC samples within the CMSSW framework, where full detector simulation is performed using GEANT4. This section is completely independent of the earlier ones.

MC generation in CMS follows a standard sequence: Gridpack > LHEGS > Premix > AODSIM > MINIAODSIM > NANOAODSIM. These steps include event generation (e.g., MadGraph), parton showering and hadronization (Pythia), detector simulation (GEANT4 via CMSSW), and full reconstruction. Each step is configured through CMSSW fragments, and production is aligned with centrally defined campaign configurations. Users generate gridpacks using the gridpack_generation.sh script from the GitHub:genproductions/MadGraph5_aMCatNLO tool, specifying the model and process. For central production, the gridpack, Pythia fragment, number of events, and other metadata are provided to the NPS MC contact. For local validation, the gridpack is processed with cmsDriver.py to create GEN-SIM or full AOD workflows.

Prerequisites

• Access to CMS computing grid (lxplus).
• Access to CRAB client and gridpack tools.
• CMS VOMS proxy, incase any external file used during production (such as pile-up profile).
• A BSM model UFO file (contact a theorist for this).
• Required cards/fragments in correct format (discuss this with the NPS MC contact).

Setting up the work area

As an example, I am producing a VLL doublet (electron type) sample with mass of both new leptons being 600 GeV. I prepared some helper scripts to manage and organize the outputs. These are to be brought to the work area as follows.

1. modeldict.yaml: YAML file containing information on the signal models. This is used to auto-generate the cards from a template.
2. Template cards which can be customized according to the needs of each model:
   • templates/proc_card_doublet.dat
   • templates/proc_card_singlet.dat
   • templates/run_card.dat
   • templates/extramodels.dat
   • templates/customizecards.dat
3. Python scripts to generate the cards and gridpacks:
   • generate_cards.py
   • generate_one_gridpack.py
4. Python script for organization:
   • move_cards.py

Next, the genproductions tool is cloned inside a directory named Run3.

                mkdir Run3 && cd Run3
                git clone https://github.com/cms-sw/genproductions.git --depth=1
              

                mkdir Run2 && cd Run2
                git clone https://github.com/cms-sw/genproductions.git --depth=1 -b mg265UL
              

At this point, the work area should look like this:

                .
                ├── Run3
                │   └── genproductions.
                ├── generate_cards.py
                ├── generate_one_gridpack.py
                ├── modeldict.yaml
                ├── move_cards.py
                └── templates
                    ├── customizecards.dat
                    ├── extramodels.dat
                    ├── proc_card_doublet.dat
                    ├── proc_card_singlet.dat
                    └── run_card.dat
              

Generating cards

The card generation is automatically handled by generate_cards.py which loops over the different mass points described in the YAML file, fills up the parameters (such as beam energy, decay leptons, masses of the VLLs etc.) in the template cards and creates a set of cards for each mass point. After this, move_cards.py is used to move the generated cards to the genproductions/bin/MadGraph5_aMCatNLO/cards/VLL directory. Now the setup is ready to generate gridpacks. At this point, relevant files/directories in the genproductions setup should look like this:

                .
                └── Run3
                    └── genproductions
                        └──bin
                            └──MadGraph5_aMCatNLO
                                ├── PLUGIN
                                ├── Utilities
                                ├── cards
                                │   └── VLL
                                └── gridpack_generation.sh
              

A note on VLL M-100: In the cards, the logic for producing the vector-like charged lepton L, and the neutral lepton N (both of which couple to muons in this example) is the following.

                define lepton = mu+ mu- vm vm~                                                          # Taken from YAML
                generate p p > L L, (L > z lepton), (L > h lepton)                                      # Pair production
                add process p p > N N, (N > w+ lepton), (N > w- lepton)                                 # Pair production
                add process p p > L N, (L > z lepton), (L > h lepton), (N > w+ lepton), (N > w- lepton) # Associated production
              

However, there is an issue with these for the low mass-point. For M = 100 GeV, some of the decay chains (e.g., L > higgs + lepton with mH = 125 GeV) are not kinematically allowed (if the Higgs is on-shell). So MadGraph tries to include these subprocesses but fails midway. The same thing is true for the associated production. The gridpack generation tries to compile all 24 processes regardless of whether they are viable or not. If even one fails, the entire gridpack generation fails. MadGraph is designed to produce on-shell bosons with minimal instructions, and it is safe to skip this mass point if it's not too important.

Generating one gridpack

Just to generate one gridpack, the following command can be run from the genproductions/bin/MadGraph5_aMCatNLO directory.

                chmod +x gridpack_generation.sh
                ./gridpack_generation.sh VLLD_ele_M600 cards/VLL/VLLD_ele_M600 local ALL el8_amd64_gcc10 CMSSW_12_4_8
              

Where,

• VLLD_ele_M600: Name of the gridpack to be generated.
• cards/VLL/VLLD_ele_M600: Path to the process card directory.
• local: Run mode (condor can be used here).
• ALL: Indicates that all available cores should be used. Number of cores can also be mentioned here.
• CMSSW_12_4_8: Version of CMSSW to be used for the subsequent steps.
• el8_amd64_gcc10: SCRAM architecture (must be compatible with the CMSSW release).

To simplify the process, I have automated gridpack generation using generate_one_gridpack.py. This script automatically sets the run mode, SCRAM architecture, and CMSSW version - requiring only the sample name as input. After generating the gridpack, it also transfers the output to EOS to conserve space in the AFS workspace. The script can be executed from the base working directory as shown below:

 python3 generate_one_gridpack.py --name VLLD_ele_M600

Full automation has not been implemented for this setup, as gridpack generation is a one-time task and the process cards are rarely modified. The resulting gridpacks will be available in the EOS directory.

↑ back to top

Gridpack validation in lxplus

This section describes the local validation of the gridpacks after they are successfully generated, i.e, the full production chain to produce NanoAOD. I am taking VLLD_ele_M600 as an example. First, pick a separate work area for validating the test gridpack and unzip it as follows.

                mkdir VLLD_ele_M600
                tar -xf VLLD_ele_M600_el8_amd64_gcc10_CMSSW_12_4_8_tarball.tar.xz -C VLLD_ele_M600
              

This creates a predefined structure required for event generation. A breakdown of the key contents is as follows:

                VLLD_ele_M600
                ├── InputCards
                ├── gridpack_generation.log
                ├── merge.pl
                ├── mgbasedir
                ├── process
                │   ├── madevent
                │   └── run.sh
                └── runcmsgrid.sh
              

• InputCards/: Contains the cards used to generate the gridpack.
• gridpack_generation.log: Full log of the gridpack creation process for debugging.
• mgbasedir/: Contains the full MadGraph installation with model files, binaries etc. needed to reproduce the generation.
• process/: Includes process-specific configuration and scripts, notably run.sh for launching the internal generation step.
• runcmsgrid.sh: The main script used to generate LHE events.

Gridpack ≫ LHE

Once the gridpack has been extracted, parton-level events in LHE (Les Houches Event) format can be produced using the runcmsgrid.sh script. This script is included inside the unpacked gridpack directory and serves as the interface to MadGraph, MadSpin (if applicable), and Pythia (if configured). It prepares the runtime environment, handles all necessary steps of event generation, and produces a cmsgrid_final.lhe file containing the events. To run the script for a small test sample of events:

                cd VLLD_ele_M600
                ./runcmsgrid.sh 1000 12345 4
              

Where:

• 1000 is the number of events to generate
• 12345 is the random seed
• 4 is the number of threads or parallel jobs to use

This also creates a temporary CMSSW environment under the hood and ensures all dependencies are properly set up for the run. The output file cmsgrid_final.lhe contains all the generated parton-level four-vectors, with each event uniquely defined. Make sure to generate enough events here to support the statistics needed for downstream steps such as full simulation and analysis.

LHE ≫ GENSIM

This step takes the parton-level LHE events and runs hadronization and particle showering using Pythia8 to produce GEN-SIM files that simulate particles and their interactions with the detector. A CMSSW configuration is required for this step. The gridpack was produced with CMSSW_12_4_8. However, I will proceed with CMSSW_13_0_13 to match 2022 (preEE) MC conditions. First, set up the CMSSW environment and directory structure as follows.

                echo $SCRAM_ARCH   # It has to be compatible with the target CMSSW release
                cmsrel CMSSW_13_0_13
                cd CMSSW_13_0_13/src/
                mkdir -p Configuration/GenProduction/python/
              

The Configuration/GenProduction/python directory is used to store the fragment (configuration script) describing how to hadronize the LHE events. The directory structure is important because cmsDriver.py (configuration maker tool) expects fragments to be in the Python path under this namespace. Here is an example of a hadronizer, without using externalLHEProducer (since we are testing a local LHE file).

                import FWCore.ParameterSet.Config as cms

                from Configuration.Generator.Pythia8CommonSettings_cfi import *
                from Configuration.Generator.MCTunes2017.PythiaCP5Settings_cfi import *            ## Used till 2022
                #from Configuration.Generator.MCTunesRun3ECM13p6TeV.PythiaCP5Settings_cfi import * ## From 2023 onwards
                from Configuration.Generator.PSweightsPythia.PythiaPSweightsSettings_cfi import *

                generator = cms.EDFilter("Pythia8ConcurrentHadronizerFilter",
                    comEnergy = cms.double(13600.),
                    maxEventsToPrint = cms.untracked.int32(1),
                    pythiaPylistVerbosity = cms.untracked.int32(1),
                    pythiaHepMCVerbosity = cms.untracked.bool(False),
                    nAttempts = cms.uint32(1),
                    PythiaParameters = cms.PSet(
                        pythia8CommonSettingsBlock,
                        pythia8CP5SettingsBlock,
                        pythia8PSweightsSettingsBlock,
                        parameterSets = cms.vstring(
                            'pythia8CommonSettings',
                            'pythia8CP5Settings',
                            'pythia8PSweightsSettings'
                        )
                    )
                )

                ProductionFilterSequence = cms.Sequence(generator)
              

Call it myfragment.py. Once the fragment is in place, compile the setup.

                scram b -j8
                which cmsDriver.py
              

This should display the path to the cmsDriver.py available in the current CMSSW environment. This tool is used to convert the generated LHE file into a GEN-SIM file. However, for debugging purposes, it is often useful to generate a configuration file first using the --no_exec option. This config file can be inspected or modified before executing. Adjust filenames, number of events, and detector-specific settings like beamspot and global conditions as needed. In the following, I am following an example of Run3Summer22 (pre-EE) conditions.

                cmsDriver.py Configuration/GenProduction/python/myfragment.py \
                  --filein file:../../cmsgrid_final.lhe \
                  --fileout file:VLLD_ele_M600_GENSIM.root \
                  --mc \
                  --eventcontent RAWSIM \
                  --datatier GEN-SIM \
                  --beamspot Realistic25ns13p6TeVEarly2022Collision \
                  --step GEN,SIM \
                  --nThreads 8 \
                  --geometry DB:Extended \
                  --era Run3 \
                  --conditions 130X_mcRun3_2022_realistic_v5 \
                  --customise Configuration/DataProcessing/Utils.addMonitoring \
                  --python_filename cfg_1_GENSIM.py \
                  --no_exec \
                  -n 100
              

This creates a configuration file named cfg_1_GENSIM.py without running the job immediately. Matching the parameters - --conditions, --beamspot, and --era with the intended simulation campaign and CMSSW release is important. Finally, run the generation step.

cmsRun cfg_1_GENSIM.py

This produces a GEN-SIM ROOT file named VLLD_ele_M600_GENSIM.root from the LHE input, suitable for the next simulation steps. This file contains both the generator-level information (i.e. final-state particles from MadGraph/Pythia) and the full detector simulation output from GEANT4, which emulates how those particles would interact with the CMS detector. This includes simulated energy deposits, tracking hits, and digitized detector responses. The GEN-SIM step is notably slow and computationally heavy because of the detailed physics and geometry involved in the simulation. While crucial for realistic MC production, such jobs are typically done on grid resources rather than locally, except for small-scale validation like this. During the validation, it also runs the GenXsecAnalyzer, which computes the cross-section of the generated events, and displays the time taken per event. Estimation of time-per-event and size-per-event is needed so that PdmV can estimate how long the central production might take.

GENSIM ≫ DIGIRAW

In this step, the simulated detector hits are converted into raw detector data format, and this is where pileup interactions can be added by overlaying minimum bias events on top of the hard scattering. Access to pileup datasets from DBS requires a valid VOMS proxy. In this example, I am not providing a pileup dataset.

                cmsDriver.py step1 \
                  --filein file:VLLD_ele_M600_GENSIM.root \
                  --fileout file:VLLD_ele_M600_DIGIRAW.root \
                  --eventcontent FEVTDEBUGHLT \
                  --datatier GEN-SIM-DIGI-RAW \
                  --step DIGI,L1,DIGI2RAW,HLT:@fake2 \
                  --nThreads 8 \
                  --geometry DB:Extended \
                  --era Run3 \
                  --conditions 130X_mcRun3_2022_realistic_v5 \
                  --beamspot Realistic25ns13p6TeVEarly2022Collision \
                  --customise Configuration/DataProcessing/Utils.addMonitoring \
                  --python_filename cfg_2_DIGIRAW.py \
                  --no_exec \
                  --mc \
                  -n 100
              

cmsRun cfg_2_DIGIRAW.py

DIGIRAW ≫ AOD

In this step, the full detector reconstruction is performed on the RAW or DIGIRAW data, producing reconstructed physics objects such as tracks, jets, electrons, and muons. This completes the previous digitization step and produces fully analysis-ready objects.

                cmsDriver.py step2 \
                  --filein file:VLLD_ele_M600_DIGIRAW.root \
                  --fileout file:VLLD_ele_M600_AOD.root \
                  --eventcontent AODSIM \
                  --datatier AODSIM \
                  --step RAW2DIGI,L1Reco,RECO,RECOSIM \
                  --nThreads 8 \
                  --geometry DB:Extended \
                  --era Run3 \
                  --conditions 130X_mcRun3_2022_realistic_v5 \
                  --beamspot Realistic25ns13p6TeVEarly2022Collision \
                  --customise Configuration/DataProcessing/Utils.addMonitoring \
                  --python_filename cfg_3_AOD.py \
                  --no_exec \
                  --mc \
                  -n 100
              

cmsRun cfg_3_AOD.py

AOD ≫ MINIAOD

MINIAOD is a reduced format derived from AOD where reconstruction is not redone but the data is skimmed and slimmed to contain only essential reconstructed objects and variables. Some high-level corrections and possibly DNN-based identification variables can be added at this stage.

                cmsDriver.py step3 \
                  --filein file:VLLD_ele_M600_AOD.root \
                  --fileout file:VLLD_ele_M600_MINIAOD.root \
                  --eventcontent MINIAODSIM \
                  --datatier MINIAODSIM \
                  --step PAT \
                  --nThreads 8 \
                  --geometry DB:Extended \
                  --era Run3 \
                  --conditions 130X_mcRun3_2022_realistic_v5 \
                  --beamspot Realistic25ns13p6TeVEarly2022Collision \
                  --customise Configuration/DataProcessing/Utils.addMonitoring \
                  --python_filename cfg_4_MINIAOD.py \
                  --no_exec \
                  --mc \
                  -n 100
              

cmsRun cfg_4_MINIAOD.py

MINIAOD ≫ NANOAOD

NanoAOD further reduces the data size for fast physics analysis, containing selected reconstructed objects and variables, often including DNN outputs for particle identification or event classification. No reconstruction is performed here; it uses the objects produced in previous steps.

                cmsDriver.py step4 \
                  --filein file:VLLD_ele_M600_MINIAOD.root \
                  --fileout file:VLLD_ele_M600_NANOAOD.root \
                  --eventcontent NANOAODSIM \
                  --datatier NANOAODSIM \
                  --step NANO \
                  --nThreads 8 \
                  --geometry DB:Extended \
                  --era Run3 \
                  --conditions 130X_mcRun3_2022_realistic_v5 \
                  --beamspot Realistic25ns13p6TeVEarly2022Collision \
                  --customise Configuration/DataProcessing/Utils.addMonitoring \
                  --python_filename cfg_5_NANOAOD.py \
                  --no_exec \
                  --mc \
                  -n 100
              

(cmsRun cfg_5_NANOAOD.py)>nanoaod.log

Important links

• Running local validation in condor
• SUS contacts
• Generator fragments repository