--+ Instructions to run the pi0/eta intercalibrations

ECALPro code to produce intercalibration constants (CMSSW 12_3_0_pre2)

Installation instructions (note that the release and branch to be used might not be updated, yet the logic stays the same):

• New users should fork the ECALELF repository
• Then, set up your working area on AFS, and setup a 123X branch, which was used for the Run 2 Ultra Legacy Run calibration
• There are older branches available, as 94X, but they are not updated. The inter calibration constants (IC) for Run 2 Ultra-Legacy (UL) were obtained from CMSSW_10_5_0 and CMSSW_10_6_8. However, the code might already exist for newer releases as well.

At the moment, we have up-to-date branches for usage in 12_3_X. Please refer to https://github.com/emanueledimarco/ECALpro, branch name is 123X.

Show the recipe (for 12_3_X) Hide the recipe

setenv SCRAM_ARCH slc7_amd64_gcc10   # for tcsh, if you have bash use:  export SCRAM_ARCH='slc7_amd64_gcc10'
cmsrel CMSSW_12_3_0_pre2
cd  CMSSW_12_3_0_pre2/src
cmsenv
git cms-init
git remote add pi0_emanuele git@github.com:emanueledimarco/ECALpro.git
git clone --branch 123X -o pi0_emanuele git@github.com:emanueledimarco/ECALpro.git CalibCode #  download code from branch 123X
cd CalibCode
YOUR_GITHUB_REPOSITORY=$(git config user.github) # or set it manually if this doesn't work for you
git remote add origin git@github.com:$YOUR_GITHUB_REPOSITORY/ECALpro.git
git checkout -b 123XX_yourPersonalBranch
git push origin 123XX_yourPersonalBranch
cd ..
scram b -j 8

git push origin 106X_yourPersonalBranch

Intercalibration framework in a nut shell

The goal of this code is to compute intercalibration constants for the crystals of ECAL. The intercalibration procedure uses photons from decays of low mass resonances (π0 and η0 particles) to equalize the variations of the energy response among different channels of ECAL, exploiting the position of the diphoton invariant mass peak measured in each channel. The events used for the intercalibration are selected with a special trigger stream at HLT, the π0/η0 stream, which has 4 HLT paths (π0/η0 separately for EB and EE):

• AlCa_EcalPi0EBonly_v
• AlCa_EcalPi0EEonly_v
• AlCa_EcalEtaEBonly_v
• AlCa_EcalEtaEEonly_v

The average event size is 2 kB/event, which is roughly 1% of the usual size of events saved in other physics datasets. This feature is achieved by saving only a minimum amount of information coming from ECAL. Photons from π0/η0 are defined as simple 3x3 matrices of ECAL crystals, and are paired to form pi0/eta candidates. The pairs that pass a predefined selection are saved in the output collections in Digis format. In other words, the stream output only contains collections of ECAL Digis (plus some other collections like the L1 trigger flags and (since November 2017) ECAL selective readout flags). The event content of an AlCaP0 file is shown below (obtained using edmDumpEventContent command)

Show stream event content Hide stream event content

Type                                  Module                      Label             Process   
----------------------------------------------------------------------------------------------
edm::TriggerResults                   "TriggerResults"            ""                "HLT"     
BXVector<GlobalAlgBlk>                "hltGtStage2Digis"          ""                "MYHLT"   
BXVector<GlobalExtBlk>                "hltGtStage2Digis"          ""                "MYHLT"   
BXVector<l1t::EGamma>                 "hltGtStage2Digis"          "EGamma"          "MYHLT"   
BXVector<l1t::EtSum>                  "hltGtStage2Digis"          "EtSum"           "MYHLT"   
BXVector<l1t::Jet>                    "hltGtStage2Digis"          "Jet"             "MYHLT"   
BXVector<l1t::Muon>                   "hltGtStage2Digis"          "Muon"            "MYHLT"   
BXVector<l1t::Tau>                    "hltGtStage2Digis"          "Tau"             "MYHLT"   
EBDigiCollection                      "hltAlCaEtaEBRechitsToDigis"   "etaEBDigis"      "MYHLT"   
EBDigiCollection                      "hltAlCaPi0EBRechitsToDigis"   "pi0EBDigis"      "MYHLT"   
EEDigiCollection                      "hltAlCaEtaEERechitsToDigis"   "etaEEDigis"      "MYHLT"   
EEDigiCollection                      "hltAlCaPi0EERechitsToDigis"   "pi0EEDigis"      "MYHLT"   
edm::SortedCollection<EBSrFlag,edm::StrictWeakOrdering<EBSrFlag> >    "hltAlCaEtaEBRechitsToDigis"   "etaEBSrFlags"    "MYHLT"   
edm::SortedCollection<EBSrFlag,edm::StrictWeakOrdering<EBSrFlag> >    "hltAlCaPi0EBRechitsToDigis"   "pi0EBSrFlags"    "MYHLT"   
edm::SortedCollection<EESrFlag,edm::StrictWeakOrdering<EESrFlag> >    "hltAlCaEtaEERechitsToDigis"   "etaEESrFlags"    "MYHLT"   
edm::SortedCollection<EESrFlag,edm::StrictWeakOrdering<EESrFlag> >    "hltAlCaPi0EERechitsToDigis"   "pi0EESrFlags"    "MYHLT"   
edm::SortedCollection<EcalRecHit,edm::StrictWeakOrdering<EcalRecHit> >    "hltAlCaEtaRecHitsFilterEEonlyRegional"   "etaEcalRecHitsES"   "MYHLT"   
edm::SortedCollection<EcalRecHit,edm::StrictWeakOrdering<EcalRecHit> >    "hltAlCaPi0RecHitsFilterEEonlyRegional"   "pi0EcalRecHitsES"   "MYHLT" 

Intercalibration code in a nut shell

The code is mainly made of 2 parts:

• CalibCode/FillEpsilonPlot/src/FillEpsilonPlot.cc
• CalibCode/FitEpsilonPlot/src/FitEpsilonPlot.cc

The first source file takes as input the collections of ECAL RecHits, builds the clusters and fills the mass distributions for each crystals from the pairs of clusters passing the selections. The second source takes the mass distributions and fits them to get the position of the peak, from which the intercalibration constants are obtained. These sources are executed through some python scripts in CMSSW format, splitting EB and EE into bunches of crystals that are analyzed running condor jobs.

All the code is managed by the main python script, submitCalibrationCondor.py. It creates all the output folders and the python configuration files used to run the real code (the .cc source mentioned before). Last but not least, it launches a condor job (the daemon) to execute calibJobHandlerCondor.py. This latter script is the very core of the calibration code, for it submits all the jobs that run the code, managing histograms filling and fitting and creating the calibration maps.

• Note that since 2018, these scripts substitute the old ones (without Condor in their names) that were running jobs using lxbatch on the caf queues. The old scripts might still work but are no longer being kept up to date.

How to run the calibration code

The instructions here uses the version of the code that runs jobs using condor. You need to be on lxplus to have the code work. Also, in order to access eos files not stored at cern, you should create a proxy using the following commands

voms-proxy-init --voms cms --rfc --valid 168:00
mv /tmp/x509up_<xxxx> <your_path_on_afs>/X509_USER_PROXY
export X509_USER_PROXY='<your_path_on_afs>/X509_USER_PROXY' 

Which requires a grid certificate registered to VO. In this way it will be possible to read dataset stored outside cern. Last command is for bash shell: in case you have tcsh, the command to use is the following:

setenv X509_USER_PROXY <your_path_on_afs>/X509_USER_PROXY

You can put the last command in your .bashrc so that you will just need to use voms-proxy-init --voms cms --rfc --valid 168:00. Now you are ready to run the calibration.

CMS has dedicated resources in a separate htcondor pool, dedicated for CAF activity. You may want to exploit them to run your jobs. See here to find how: CMS_CAF_T0

Preparing the AlCaP0 files to run on:

First of all, you need to download a list of files created by the HLT stream during data taking. This is the data you run on to compute the inter-calibration constants. This step can be managed using the script getFilesAlCaP0.sh in the main folder.

Basically, it runs the dasgoclient command to query the DAS database and retrieve the files. Then, the same script also runs Utilities/Purify_List.py, which filters the list previously created using a JSON file (specified inside getFilesAlCaP0.sh ). This is useful to make the calibration faster, as many files might be rejected by the JSON you are using. The script is also supposed to run brilcalc on the JSON file to tell you the integrated luminosity you are going to use, but it is possible that brilcalc might not work, for a wide range of reasons. Either make sure you can run brilcalc, or comment out the lines that would use it.

At the end of this step, this list of files will have to be set in the main configuration file, parameters.py, as explained in the following.

Setting the code and running:

First of all, set up things in parameters.py configuration file (for a description of the most relevant parameters, see the section "Some hints on how to use the code" below). Then, you only need to run ./submitCalibrationCondor.py from inside the CalibCode/submit/ folder. This will create folders on EOS to store the output root files. At the same time, a local folder with all the configuration files is created as well: this folder is also used to store log files produced by the code and other scripts to run jobs.

cd $CMSSW_BASE/src/CalibCode/submit
./submitCalibrationCondor.py -l [-c]

Use option -c to prevent the code from submitting jobs: it will just create all folders and files, allowing you to do local tests. Even if you don't submit jobs at this step, the command to be used to do so will be printed on the stdout for later usage. When making such tests, it is suggested to set nIterations to 1 in parameters.py, to avoid producing tons of unnecessary files, which takes time. For the same reason, it is better to set inputlist_n to a file that contains only a small fractions of the AlCaP0 files to run on.

Use option -l to run the main daemon locally. This is currently needed because the nested job submission was imported from the previous code using lxbatch, but it doesn't work yet with Condor (need a proper implementation using DAGman). For the moment, the -l flag is set to True by default to avoid mistakes. There are also other options which you might want to use.

Running the daemon locally is just a temporary solution: the problem is that you are forced to renew the LSF token every day (you could create it for more days using kinit -l 7d, but this doesn't always work for me) and it can make the code crash, because calibJobHandlerCondor.py need to create and copy some files on the /afs/ area. Running the daemon locally has the advantage of allowing you to directly monitor what the code is doing or whether few jobs are running indefinitely, but it has the big disadvantage of preventing you from exiting the lxplus session. As the process of producing IC takes a long time (order of days), you should make use of a terminal multiplexer like GNU screen, which allows you to keep the working session running even if you log out. One trick to automatically renew the ads token is to use option -t passing as argument a temporary txt file which contains your afs password to renew the token. Of course this txt file should be created in a private folder that only you can access (in this way, if someone is able to read that folder and the file, it means they already have your password). However this solution is highly deprecated.

Jobs sumitted by calibJobHandlerCondor.py can be monitored locally from lxplus using condor_q and options therein. For easier bookkeeping, they are assigned a specific name that depends on what they do. An example is shown below.

Show output of condor_q Hide output of condor_q

[mciprian@lxplus030 submit]$ condor_q


-- Schedd: bigbird15.cern.ch : <188.184.90.241:9618?... @ 03/06/19 16:17:54
OWNER    BATCH_NAME      SUBMITTED   DONE   RUN    IDLE  TOTAL JOB_IDS
mciprian ecalpro_Fill   3/4  20:03   2269     42   1658   3969 1720566.2011-3968

1700 jobs; 0 completed, 0 removed, 1658 idle, 42 running, 0 held, 0 suspended
[mciprian@lxplus030 submit]$

The possible jobs' names (below the BATCH_NAME field) are:

• ecalpro_Fill: they fill the pi0/eta invariant mass distributions (this is the step taking the largest fraction of time, order of some hours depending on how many AlCaP0 files are processed by each job)
• ecalpro_Fill_recovery: they rerun the ecalpro_Fill jobs that failed (not used for standard calibration flow, we can afford to lose some jobs so we prefer not to waste time here)
• ecalpro_Hadd: they merge the histograms created by the ecalpro_Fill jobs (because the total dataset is split into several jobs, whose outputs must be merged using the ROOT hadd command)
• ecalpro_Hadd_recovery: they rerun the ecalpro_Hadd jobs that failed
• ecalpro_FinalHadd: just one job, which merges the outputs of the ecalpro_Hadd jobs into a single root file
• ecalpro_Fit: they run the fits to the mass distributions (they are 31 for EB and 8 for EE). Their outputs are then merged inside calibJobHandlerCondor.py without submitting further jobs.

These names follow the main steps of the calibration flow: filling mass distributions, merging the histograms (+ 1 final merge) and fitting. The code periodically checks if some jobs are still running before moving to the next steps. This is done automatically by the code itself, which runs condor_q filtering the outputs by their name and counting how many of them are present.

IMPORTANT: From time to time the condor_q command might fail, producing an unexpected output. If this happens, the code might count 0 jobs and move to the next steps. The checkNjobsCondor function implemented inside calibJobHandlerCondor.py should be able to catch such errors and dealt with them. However, it is not guaranteed that everything will work as expected.

Therefore, it is highly recommended to check the jobs manually more than once a day. If you see different types of jobs running in parallel (generally it will happen that some ecalpro_Fill jobs are running along with other ones with different names), kill the code and all the jobs that are not named as ecalpro_Fill. Then, after waiting for the ecalpro_Fill jobs to end their course, you will have to resume the calibration flow from the Hadd step, as explained in the following section below.

In case the failure prevented some of the ecalpro_Fill jobs to complete successfully, it is probably better to rerun that iteration from the beginning. However, if only a small fraction of jobs failed, you can still resubmit them by resuming from the Hadd part. Indeed, the code checks for missing files produced by the ecalpro_Fill step, and automatically resubmit them if you used the option --recover-fill. You can also set a tolerance for the minimum fraction of failed jobs that must be reached in order to to resubmit them (you don't really need all data to calibrate), using option --min-efficiency-recover-fill (by default it is set to 0.97).

Resume a calibration:

• -i [value]: an integer for number of the iteration to be resumed. It can be an integer number from 0 to N-1, where N is the total number of iterations you set in the beginning inside parameters.py. The possible values start from 0 because the output folders are named as iter_X, with X starting from 0
• -s [value]: an integer (0, 1 or 2). The default value is 0, and means running on all event. The other values are used to run on either even or odd events (this can be needed when computing the statistical uncertainty on the calibration constants)
• -r [value]: a string to select from which step of the calibration the resubmission should start from (obviously this only affects the first resubmitted iteration, indeed once it is over the following one will run the whole chain). The argument passed to option -r can take these values:
  • hadd: only the merging (ecalpro_Hadd jobs)
  • finalhadd: only the final merge (ecalpro_FinalHadd job)
  • fit: only the fits (ecalpro_fit jobs)
  • mergefit: only the final merging of the outputs of the fits (this is done locally, no job is used)
• -n [value]: an integer for the number of jobs, which must be equal to the total number of ecalpro_Fill jobs managed by the code, regardless whether you are resuming a different step of the calibration flow. It can be found inside the submit.sh script saved inside the output folder in the afs local area where you launched the calibration in the beginning ( the number 5557 in the example below, where the local folder was called AlCaP0_AllRun2017_condor)

Show example Hide example

[mciprian@lxplus030 submit]$ pwd
/afs/cern.ch/work/m/mciprian/myEcalElf/ultraLegacyRun2/2017/CMSSW_9_4_5/src/CalibCode/submit
[mciprian@lxplus030 submit]$ cat AlCaP0_AllRun2017_condor/submit.sh 
#!/bin/bash
cd /afs/cern.ch/work/m/mciprian/myEcalElf/ultraLegacyRun2/2017/CMSSW_9_4_5/src/CalibCode/submit
ulimit -c 0
eval `scramv1 runtime -sh`
python /afs/cern.ch/work/m/mciprian/myEcalElf/ultraLegacyRun2/2017/CMSSW_9_4_5/src/CalibCode/submit/calibJobHandlerCondor.py 5557 cmscaf1nd
rm -rf /afs/cern.ch/work/m/mciprian/myEcalElf/ultraLegacyRun2/2017/CMSSW_9_4_5/src/CalibCode/submit/core.*
[mciprian@lxplus030 submit]$ 

NOTE: When using hadd to merge files, the list of files to be merged is stored in some dedicated files stored in localfolder/src/hadd/, where localfolder is the name of the local folder containing all the relevant files to manage the calibration (the specific name is set in dirname inside parameters.py). These files are created when submitting the calibration the first time and are named as hadd_iter_XX_step_YY.list, where XX and YY are integer numbers. Each of them contains a bunch of paths to eos (the actual number of files depends on the settings in the configuration file), pointing to the ROOT files that are expected to be created by the ecalpro_Fill jobs. Given that some jobs can fail, some of these files might be missing. This would cause hadd to fail, so the code makes a check of the files actually present on EOS and create new lists of files, called hadd_iter_XX_step_YY_pruned.list, that are then copied into the original ones (the original lists are saved into hadd_iter_XX_step_YY_backup.list files) Therefore, before resubmitting the calibration, one should use the script copyBackupListToOriginal.sh to copy the backup files into the original ones again (it also deletes all the pruned and backup files afterwards). This step is paramount in case the ecalpro_Hadd jobs started before all the ecalpro_Fill jobs completed their course (it should never happen in an ideal world, but in the real world it did happen).

Ouput files on EOS:

• AlcaP0_test_EcalNtp_XX.root for ecalpro_Fill jobs
• AlcaP0_test_epsilonPlots_YY.root for ecalpro_Hadd jobs
• AlcaP0_test_epsilonPlots.root for the single ecalpro_FinalHadd job (note that the number YY is not present in the name, unlike for the eclpro_Hadd jobs)
• AlcaP0_test_Barrel_NN_calibMap.root for ecalpro_Fit jobs in EB (they are always 31 jobs, each one manages 2k crystals, unless differently specified in the configuration file)
• AlcaP0_test_Endcap_MM_calibMap.root for ecalpro_Hadd jobs in EE (8 jobs)
• AlcaP0_test_calibMap.root: this contains the final calibration map (created locally, no jobs) obtained merging the single pieces above

The ecalpro_Fit jobs also saves the fits for each crystal in a TCanvas and RooPlot format. The output root files are named as the ones with the calibration maps, changing calibMap with fitRes keyword (they are not merged in a single file at the moment, it is not really necessary).

Deleting unnecessary output files on EOS

To manage this deletion, you can use the script Utilities/deleteEOSfile.sh, where you can set the iterations to be affected.

Useful notes

Work in progress ...

After calibration workflow

Twiki with Global Tags:

• You should know the Global Tag that you used to run the pi0 code. A twiki with the list of central GTs is here
• to find the tag of the intercalibrations inside the GT use the GT browser
  • put the GT name in the search box (eg. 80X_dataRun2_Prompt_v8)
  • search in the Tag List the record: EcalIntercalibConstants
  • the tag is EcalIntercalibConstants_V1_express (eg for the GT above)

Make maps with IC

There are some utility scripts to make plots in AfterCalibTools/PlotMaker/

Work in progress

Make plots to monitor the goodness of the IC

One can make the plots to show the convergence of IC using AfterCalibTools/TestConvergence/Convergence.sh

Work in progress

Some hints on how to use the code.

Here it is assumed you downloaded the code into a directory named CalibCode.

First of all, you need to set the variables in CalibCode/submit/parameters.py. NOTE: since spring 2017 EOS is monted on lxplus, which means the previous eos syntax is not needed anymore. Bash commands like ls, cp, ..., can be used as if EOS is a local folder (only if working from lxplus, not from a local pc for example). The consequence is that some of the following parameters might not be needed anymore (I'm trying to update the documentation, but keep that in mind in case I have missed something). However, keep in mind that it is better not to use the eos mount to access files on EOS, as it can create overload of the filesystem. For instance, to copy files to eos it is better to use the xrdcp command or eos cp.

The following is a list of the main parameters you have to set:

eosPath: this is the path on EOS where the output files of ECALpro are stored. We have a dedicated space in /eos/cms/store/group/dpg_ecal/alca_ecalcalib/piZero_Run2/ . You can create your own folder named as your nice username (make sure you have permission to create and write inside ths space). E.g., in my case I have eosPath = '/eos/cms/store/group/dpg_ecal/alca_ecalcalib/piZero_Run2/mciprian'. Generally speaking, it should be possible to create new folders in /eos/cms/store/group/dpg_ecal/alca_ecalcalib/.

isDebug: if True, activates some couts in FillEpsilonPlots.cc to keep track of the analyzer flow (as the name suggests, it is only useful for debugging purposes). It was implemented to avoid #define directives previously used in the FillEpsilonPlots.cc.

isEoverEtrue: this is used with MC to compute E/Etrue containment corrections. If False (default with data), the usual calibration based on pi/eta mass is performed.

foldInSuperModule: if True, all supermodules are folded into one (clearly it is for EB only). It was necessary to derive containment corrections with E/Etrue due to lack of statistics, but it can be used for calibration as well

MakeNtuple4optimization: if True, it saves some TTrees with useful variables (pi0 pT, mass, photons kinematic information ...) that can be used to perform optimization studies. See directly the code in CalibCode/FillEpsilonPlot/src/FillEpsilonPlot.cc for more details. When this flag is set to True, only one iteration will be done and only the unmerged ntuples (\*EcalNtp\*.root files) are created, which saves time and storage space (you can run your macro on them using a TChain).

dirname: name of the folder where output files are stored. A folder with this name is created inside eosPath (root files will be saved here) and locally in /CalibCode/submit/ (the local directory is the one where all the config files, log files and other scripts are created).

NameTag: name used as prefix for the root files on produced on EOS. We suggest naming this parameter as dirname followed by _, but it is not mandatory to run the code.

nIterations: number of iterations that are submitted. For each of them, a folder iter_n is created in eosPath/dirname/, where n goes from 0 to nIterations-1. We suggest keeping nIterations < 10. The reason is that a big number of files are created locally inside dirname (one for each job submitted by ECALpro) and there is a maximum number of files that can be stored in that folder (this could be an internal setting of AFS). When you try to create more files, the code will complain and stop execution before actually submitting the jobs. The limit depends on the number of files are in inputlist_n and how many files are managed by a single job (see ijobmax). We found that up to 8 iterations can be handled without problem: this is a problem because about 14 iterations are needed to have the intercalibration constants converge. To overcome this, from 2016 there is the possibility to submit further iterations starting from another already existing set of iteration (see parameter SubmitFurtherIterationsFromExisting).

SubmitFurtherIterationsFromExisting: when this flag is set to true, the first iteration that is submitted (whose output is inside iter_0 on EOS) will be done on top of the calibration map of another iteration that you have already run. You also need to set the parameter startingCalibMap to the path on EOS where this map is stored

startingCalibMap: if you set SubmitFurtherIterationsFromExisting = True, this parameter gets effective. It is the EOS path to the calibration map you are using as the first step for the IC you are submitting. The format is like /store/<path-to-calibMap>/<calibMap-file-name>.root

SystOrNot: if 0, do nothing special (just run on all events as usual); if 1 or 2, run only on even or odd events. This is useful to compute the statistical error on the IC, for which you have to rerun a given iteration once on even and once on odd events. It is effective only if you start the current iteration from an existing one (SubmitFurtherIterationsFromExisting set to True): for example, if you have made 10 iterations and you want to compute the stat. uncertainty on the 10th, you would rerun the 10th iteration twice by statrting from the 9th.

ijobmax: how many files from the stream are processed by each job. If it is to low you will be submitting too many jobs, while if it is too high the job might be too heavy: in both case you are enhancing the probability to lose statistics, either because you have more potentially failing jobs or a considerable amount of data managed by a single job. A reasonable number is 5. For each job, ECAlpro runs fillEpsilonPlot.cc and a file named *EcalNtp*.root is created on EOS: these will be merged in files called *epsilonPlots*.root which, eventually, will be merged in the final *epsilonPlots.root file before running fitEpsilonPlot.cc.

nHadd: number of files that are added in bunches (here we mean output files, each one made from ijobmax stream files). In other words, how many *EcalNtp*.root files are merged in each *epsilonPlots*.root file using hadd. If the jobs that merge files fail, they are submitted again up to a given number of times before giving up. This is important because when one merge fails you are losing a considerable amount of data, which is obviously not good.

fastHadd: this flag should be True to use the fastHadd command to merge root files, otherwise normal hadd is used (the former is said to be faster). For the moment it must be left as True, but hadd is used nonetheless (work in progress to fix this, but it has low priority).

Barrel_or_Endcap: can be 'ONLY_BARREL', 'ONLY_ENDCAP', 'ALL_PLEASE' to submit IC for EB, EE or both. Typically you want to do it for both.

L1SeedExpression: this variable stores the expression of L1 seeds used by the stream. It MUST have a space as the ending character (see comments in parameters.py for details and explanation). This expression is actually only used when L1TriggerInfo is set to true: in this case, a labelled histogram called "triggerComposition" (see CalibCode/FillEpsilonPlot/src/FillEpsilonPlot.cc) is filled and counts the number of events triggered by a given L1 seed (whose name is a label on the x axis).

ContainmentCorrection: This parameter is used to choose which kind of containment corrections (CC) you want to apply. It is later used in parameters.py to set other flags that are really used in the source files. For the moment you can choose between 'EoverEtrue' (CC based on E/Etrue in MC), 'No' (no CC)

justCreateRecHits: When true, the code will run one iteration to produce RecHits from the input Digis that are stored in the files saved by the stream. This can be useful because the local reconstruction that produces RecHits from Digis is actually only needed once (the RecHits would never change) and it takes about half the total time to complete an iteration. The drawback is that this intermediate dataset can be quite large (around 1/4 of the original size of the stream, so potentially many TeraBytes). This dataset is created in the path specified with eosOutputPathForRecHits, inside which another folder named AlCaP0_RecHitsFromDigis==+_+==dirname

runCalibrationFromRecHits: if True and if you have already made an iteration with justCreateRecHits, you can start the calibration directly from RecHits.

WORK IN PROGRESS

Useful links

• ConfDB HLT browser here
• CondDB browser, to check Global tags [[https://cms-conddb.cern.ch/cmsDbBrowser/index/Prod][here]
• SWGuideFrontierConditions twiki, to check which Global tag and release to use on a given dataset [[https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideFrontierConditions?redirectedfrom=CMS.SWGuideFrontierConditions#Global_Tags_for_Data_Taking][here]