Skip to content

MCwrapper

Jump to bottom
dalton edited this page Nov 17, 2020 · 16 revisions

DEPRICATED

Project moved to https://github.com/JeffersonLab/gluex_MCwrapper

New documentation https://www.overleaf.com/read/bqynmnwstzfx

Former Documentation

Using MCwrapper assumes you have a working build of sim-recon, hdgeant, amptools, or access to a working build. It is recommended to use either the build-scripts provided by Mark I. or hdpm provided by Nathan S.

Currently, to run MCwrapper you must have the environment variable "MCWRAPPER_CENTRAL" set to be the full path to the folder containing gluex_MC.py. This is done automatically at jlab with Mark's "build-scripts" and in hdpm. Once this is done, you need to supply a config file for the wrapper. An example of such a configuration file can be found in $MCWRAPPER_CENTRAL/examples. Simply, fill out the required parameters and you are ready to run. To run: $MCWRAPPER_CENTRAL/gluex_MC.py /the/config/file/for/mcwrapper [Run number] [number of events]. A -h option is available for all of the command line options, but you may look below for a detailed description of both the configuration file and command line arguments.

The philosophy of options is that the configuration file for the wrapper itself should contain parameters that are rarely modified over the course of an analysis (e.g. the geant version). The command line arguments (which swif jobs should respect) are usually frequently changing variables (eg number of events). Currently there is no parity between the configuration file and command line options.

MC.config

CUSTOM_MAKEMC By default the wrapper will use the MakeMC.csh which is responsible for the actual production of MC. If this parameter is set to another script the wrapper will use it instead. This is useful for users developing new generators or making changes to the programs being used and still wish to produce MC in this framework.

CUSTOM_GCONTROL The intention is that Gcontrol.in can become a standard template file for Geant to use. If there is a card that is needed for an analysis and Gcontrol.in does not use it then a user can make a copy of Gcontrol, make the appropriate modifications and tell the wrapper to use this file instead.

[optional] TAG Here you may provide an optional string which will act as a prefix for all of the files produced. This can be useful if you are doing multiple runs based off of the same general chain but differ in some small way (e.g. "Flat")

[optional] CUSTOM_PLUGINS This is a comma-separated list of plugins that will be run alongside both danarest and monitoring_hists (e.g. plugin1,plugin2). You may also set this equal to file:/use/this/file.cfg to use a configuration file in hd_root. Note: this overrides any default plugins run.

DATA_OUTPUT_BASE_DIR This is simply where the output will go. The wrapper will produce many subfolders to hold the output. This directory, and all of the sub-folders, will be created if they don't exist.

GENERATOR This is the generator you wish to use. Currently on genr8, genEtaRegge, gen_2pi_amp, and gen_pi0 are supported. If a user wishes to use this frame work for other generators they may contact Thomas Britton or attempt to customize their own copy of MakeMC.(c)sh to include support. Additionally file:/my/generated/file.hddm my be chosen which will bypass the generation step in favour of using the supplied file

GENERATOR_CONFIG All generators are expected to have a configuration file necessary for proper generation. In, every case there have been slight modifications to the style of these files. This modification is necessary to provide hooks for the wrapper to do as much of the work as possible. That being said the file you have sitting around will probably work, just without the generalizations MCwrapper can provide. The one exception are the configuration files for "amptools" style generators which should now have an addtional blank line (# ) placed at the very top. For your convenience example files for all supported generators have been provided in the Generators folder.

[optional] eBEAM_ENERGY This parameter can be commented out to "rcdb" (in which case the value from rcdb will be used or, in the case of failure, a default will be used) and represents the electron beam energy of the generator in GeV

[optional] COHERENT_PEAK This parameter can be commented out or set to "rcdb" (in which case the value from rcdb will be used or, in the case of failure, a default will be used) and represents the position of the coherent peak in GeV

[optional] GEN_MIN_ENERGY This parameter can be commented out (in which case default values will be used) and represents the minimum photon energy in GeV

[optional] GEN_MAX_ENERGY This parameter can be commented out (in which case default values will be used) and represents the maximum photon energy in GeV

GEANT_VERSION Which geant version the wrapper should use. Note: This wrapper does not set hdgeant4 up if needed and assumes that your environment is configured to use hdgeant4.

BKG This is what kind of background you want to use. It can be "None" which means it will not fold in random trigger events, "BeamPhotons" which means it will use the background generated by hdgeant, a customs string for folding in random triggers (e.g. "bgfile.hddm:1.8"), or "DEFAULT"/left unset which will cause the wrapper to look for the file of random triggers matching the provided run number and use that. This default currently only works at jlab as it looks in the standard directory for files. It will be updated with a more general way to access the needed files.

NCORES This is the number of threads multi-threaded steps should use. This is also the variable that holds other information that qsub needs e.g. #ofNodes:NodeID:PPN or #ofNodes:PPN. Consult your institution for the expected form, then, if MCwrapper needs more generalizing I can do that.

[optional] SQLITEPATH This is the path to the sqlite file, which will be copied locally when used. By default it is not used.

               ===EVERYTHING BELOW FOR BATCH ONLY===

[optional] VERBOSE This is used to print out the command given to SWIF and is useful for some debugging.

BATCH_SYSTEM This is the batch system that you use. It also supports [batch system]:[queue name] for those institutions needing the queue name to be provided. Currently it supports "swif" and "qsub" with plans to support "condor" and hopefully, eventually, the OSG.

[psuedo-optional] RUNNING_DIRECTORY This is not needed for swif. qsub, however, requires a directory to run in. This is the full path of that directory. If it doesn't exist it will be created. The wrapper will cd into this directory first before assembling the necessary resources to produce your MC

WORKFLOW_NAME The workflow name swif will use. It will be created if it doesn't exist. It will use the same workflow if it does (the error can be ignored). This is also used to name the jobs in qsub

PROJECT There should be no need to change this from "gluex", but is left here if needed for future book keeping. See: sciComp Projects for more info.

TRACK There should be no need to change this from "simulation", but is left here if needed for future book keeping. See: sciComp Tracks for more info.

ENVIRONMENT_FILE This is the full path (including file) that will be sourced when running a swif job. If you use the build-scripts method in which an xml file is needed as input it is suggested to make a simple script that sources the appropriate file with the appropriate xml and reference that file here.

DISK This is the maximum disk space the each job requires.

RAM This is the maximum amount of ram each job requires.

TIMELIMIT This is the maximum walltime for each job. Some systems may require the form xx:xx:xx and is accepted by MCwrapper.

OS Specifies what OS the job will be submitted to. This can be either centos7 or centos65 and only really applies to SWIF currently

Command Line Arguments

For now call gluex_MC.py -h for help. More to come here soon.

Clone this wiki locally