Exotica Generator Contact Instructions

Resources

Setting up the McM environment

  • First time instructions:
mkdir -pv ~/workspace/private/MCI
cd ~/workspace/private/MCI
git clone https://github.com/jotadram6/Automatic-McM-EXO
chmod u+x Automatic-McM-EXO/*sh
chmod u+x Automatic-McM-EXO/*py
chmod u+x Automatic-McM-EXO/csub
cat <<EOF >setup.sh
#!/bin/bash
export PATH=~/workspace/private/MCI/Automatic-McM-EXO:\$PATH
EOF
source setup.sh
  • The scripts require python2.7, not 2.6! You can get this by setting up a recent CMSSW release, using CC7, or possibly from scl.
  • Things to do at the start of sessions:
    • Run the setup script at the start of every session, in order to have the McM scripts in your PATH.
    • voms-proxy-init
    • Run Cookies.sh (should be in your path)
    • Make sure you're using python2.7
    • Avoid having CMSSW setup unless you really need it. It interferes with Cookies.sh, and maybe other scripts that interact with MCM.

Pythia-only

Steps for submitting requests that only use Pythia.

  1. Proofread the spreadsheet: proper dataset names, generator fragment, number of events.
  2. Make sure an example generator fragment and/or a script for generating the fragments exists in the genproductions repository (this is for future reproducibility; we will use a local copy of the fragments on lxplus).
    1. The analyzer might have done this already. If not, clone the genproductions repository from github, add an example fragment and generating script to a new folder, and issue a pull request. This will usually be merged immediately.
    2. Make a note of the SHA-1 of the commit, and add it to the spreadsheet in a new columns with heading "Tag".
  3. Download CSV file and move to lxplus.
  4. Follow the directions above to setup the environment for the McM scripts.
  5. Use manageRequests.py to add the requests to McM: manageRequests -c RunIISummer15GS -t EXO-Name-# file.csv. The tag can be whatever you want; use something helpful and distinct for easy lookup later on, like EXO-MonoZ-2016-1. The Run 2 campaigns are RunIISummer15GS, RunIIFall17GS, or RunIIFall18GS. Important: write down the PrepIDs created on McM!
  6. Use list of PrepIDs to test the requests locally: testRequests.py -n 20 -i PrepIdList. It will create a CSV file with the job numbers (called by default test_.csv).
  7. When lxbatch jobs finish, get information with testRequests.py -f test.csv. This will create another CSV file (called by default results_test_.csv). This extracts metadata about the production job, like the cross section and CPU time per event.
  8. Modify requests on McM with the extracted metadata, using manageRequests.py -m results_test_.csv.
  9. Go to McM and click "next step" for requests to validate them (the little > icon). They will move to a stat with approval "validation" and status "new". Note that you can do many jobs at once by clicking the checkbox and other icons at the bottom of the page.
    1. If the validation fails, check your email to see the reason why. A common cause of failure is inaccurate time per event: McM validation requires that the measured time/event be within 40% of the written one. You can try to get a more accurate estimation by clicking the wrench icon, and specifying double the validation time.
  10. In parallel while the McM validation jobs are running, use the request_fragment_check.py script to perform a technical validation of the request. Any ERRORs should be fixed.
  11. When the request finish validation, they will say approval "validation" and status "validation". Click next step again and they will enter approval "define" and status "defined".
  12. Create the tickets (groups of requests) using makeTicket.py -i FirstRequestPrepId-LastRequestPrepId. Note that a ticket should contain at most 40 PrepIDs, so break up the PrepIDs into many tickets for larger requests.
    1. The script will ask for four things: the chain (ask on cms-exo-mcrequests if you don't know), the priority block (see MccM google doc for guidelines; =2 for very high priority like Moriond19), the number of repititions (=1), and "staged" (=0; number of times the request has been produced already).
  13. Present the tickets at Wednesday's MC coordination meeting (MCCM), include all requests that are defined. Give the PrepIDs for each set along with the number of events, dataset name, and any special conditions that they need.

Central LHE requests

Steps for submitting requests that use gridpacks like MadGraph and POWHEG.

  • Check the spreadsheet: proper dataset names, generator fragment, number of events.
  • If an example card does not exist in genproductions, have the analyzer commit the example card (and a script to generate the whole set) to genproductions and issue a pull request. For a 2017/2018 example, see PR 2026.
  • If the hadronizer is not already available on genproductions, issue a pull request for it as well.
    • Old step, maybe not needed?* When pull request is merged, get SHA-1 and add it in a column to the spreadsheet under the heading "Tag"*
  • Have analyzers link to card URL in the spreadsheet. Use a specific commit rather than pointing to the master branch, as that can change over time.
  • Download the spreadsheet as a CSV file. Remove the columns for generator fragment, fragment tag, and filter/match efficiencies. Change generators to include hadronizer (e.g., a "madgraph" request hadronized with Pythia8 becomes "madgraph pythia8"). (Old, maybe not needed? Add EOS column with value 0 for all requests.) Move to lxplus.
  • Copy gridpacks to EOS, where they will be automatically moved to cvmfs a couple hours later. This used to be done with copyGridpacks.sh file1.csv... this script no longer seems to work, so in the meantime, just use xrdcp, e.g.
eos mkdir /store/group/phys_generator/cvmfs/gridpacks/2017/13TeV/madgraph/V5_2.6.0/ZprimetoNN_EEJJJJ/
xrdcp /afs/cern.ch/work/s/shjeon/public/gridpacks/ZprimetoNN/ZprimetoNN_EEJJJJ_Zprime4000_N1500_WR5000_NLO_tarball.tar.xz root://eoscms.cern.ch//eos/cms/store/group/phys_generator/cvmfs/gridpacks/2017/13TeV/madgraph/V5_2.6.0/ZprimetoNN_EEJJJJ/
  • Edit the spreadsheet so that the "gridpack location" column points to the gridpacks on CVMFS.
  • Use manageRequests.py to add the requests to McM. For example: manageRequests -c RunIIFall17wmLHEGS -t EXO-Name-# file2.csv.
    • The campaigns are as follows: 2016=RunIISummer15wmLHEGS, 2017=RunIIFall17wmLHEGS, 2018=RunIIFall18wmLHEGS.
  • Write down the list of PrepIDs. Either use the output from the previous step, or use getRequests.py -c "tags=EXO-Name-#&member_of_campaign RunIISummer15GS "= (warning: might give wrong chains, this needs to be fixed).
  • Use list of PrepIDs to test the chained requests: testRequests.py -n 20 -i PrepIdList, where PrepIdList=firstPrepId-lastPrepId. This will create a CSV file with the job numbers, called by default test_.csv.
  • When lxbatch jobs finish, get information with testRequests.py -f test_.csv. This will create another CSV file, results_test_.csv.
  • Modify requests with manageRequests.py -m test.csv. This will update the request on McM with the information from your tests, like the time/event and size/event.
  • Go to McM (https://cms-pdmv.cern.ch/mcm/requests?range=firstPrepID,lastPrepID). Scroll to the bottom, click the square to select all requests, and click the ">" icon to launch validation. This basically repeats your local test with larger statistics, and will take several hours.
    • Old instructions: Use validateChains.py PrepIdList to validate chains. You could go to the chain and click "validate the chain" (the star button) but that can only be done one chain at a time.
    • Potential problems: if McM complains about your requests, you might have to modify it using the wrench icon. I've had to change "mcdbid" to "0", rather than "-1".
    • The jobs will start with status "validation new". If they succeed, the status will be "validation validation". If they fail, the status will be "none new".
  • When the requests finish validation, click ">" again to move the samples to "defined" status.
  • Create the tickets (groups of requests) using makeTicket.py -i FirstRequestPrepId-LastRequestPrepId. Note that a ticket should contain at most 40 PrepIDs, so break up the PrepIDs into many tickets for larger requests.
    • The script will ask for four things: the chain (ask on cms-exo-mcrequests if you don't know), the priority block (see MccM google doc for guidelines; =2 for very high priority like Moriond19), the number of repititions (=1), and "staged" (=0; number of times the request has been produced already).
  • Present the tickets at Wednesday's MC coordination meeting (MCCM), include all requests that are defined. Give the PrepIDs for each set along with the number of events, dataset name, and any special conditions that they need.

Private LHE requests

Steps for submitting requests that don't use gridpacks.

  1. Add set of requests to Exotica MC coordination twiki.
  2. Suggest setting up gridpack production for generator.
  3. Check spreadsheet: proper dataset names, generator fragment, number of events.
  4. Commit cards to genproductions and issue a pull request.
  5. If the hadronizer is not already available on genproductions issue a pull request for it as well. When pull request is merged, get SHA-1 and add it in a column to the spreadsheet under the heading "Tag"
  6. Have analyzers link to card URL in the spreadsheet. Use specific commit rather than pointing to the master branch as that can change over time. The column header should be Notes and it should say "Link to Cards: https://github.com/..."
  7. Download CSV file. Remove the columns for generator fragment, fragment tag, and filter/match efficiencies. Add dummy time (0.001 s) and size (1 kB) per event to file. Move to lxplus.
  8. Copy LHE files to EOS with sh copyPrivateLHEs.sh -i file1.csv -d 19467. Where 19467 is the EOS sub-directory that you need to create beforehand. The script will make a new CSV file with EOS filled
  9. Use manageRequests.py to add the requests to McM: manageRequests -c RunIIWinter15pLHE -t EXO-Name-# file1_EOS.csv.
  10. Click "next step" for requests to validate them.
  11. When validation is completed, click "next step" again to define the requests.
  12. Report at MCCM.
  13. When pLHE requests finish, download CSV file. Remove LHE columns. Change generators to include hadronizer (e.g., a "calchep" request hadronized with Pythia8 becomes "calchep phythia8"). Move to lxplus.
  14. Update the requests the new RunIISummer15GS requests with manageRequests -m -l -c RunIISummer15GS file2.csv.
  15. Get list of PrepIDs for requests with getRequests.py "tags=EXO-Name-#&member_of_campaign=RunIISummer15GS".
  16. Use list of PrepIDs to test the requests testRequests.py -n 20 -i PrepIdList It will create a CSV file with the job numbers called by default test.csv.
  17. When lxbatch jobs finish, get information with testRequests.py -f test.csv.
  18. Modify requests with manageRequests.py -m test.csv.
  19. Click "next step" to validate RunIISummer15GS requests.
  20. When the requests finish validation, click "next step" again to in defined the RunIISummer15GS requests.
  21. Before Wednesday's MC coordination meeting (MCCM) include all requests that are defined. Give the PrepIDs for the RunIISummer15GS requests in each set along with the number of events, dataset name, and any special conditions that they need.

Sherpa requests

Same as Pythia-only requests but the Sherpacks must be moved to EOS and copied to cvmfs. See instructions for the Sherpa interface and modify fragments accordingly.

Tags

Each new set of requests should receive its own tag formatted like EXO-Name-#. All Exotica tags should begin with EXO. They should contain the name of the analyzer who asked for the requests and a number that increments for all future requests from them. E.g., EXO-Pasquale-1.

Tips and tricks

FAQ

If you solve a problem, write down the answer here!

  • MCM validation problems
    • CPU efficiency is too low - reduce the number of cores by a factor of 2 (e.g. 8 to 4). Click on the wrench icon, select "Sequences," click the eyeball, click the wrench, adjust the number of CPUs, then click "commit" on the left to save.
  • Cloning requests
    • For simple cloning, i.e. no editing of fragments, you can use the MCM website. Click the slightly bent arrow icon.
    • For nontrivial cloning, it's better to use a script with the MCM API. See here for some examples.
    • Prod Mon is a good tool for finding all the requests to be cloned, searching by dataset name.
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r18 - 2020-12-30 - MichaelDavidKrohn
 
    • 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-2021 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