Production Campaign Checklist¶
Here we document what needs to happen before launching a new production campaign. What follows is a list of steps that need to happen, but at present the order in which they need to happen is somewhat ambiguous. To summarize the steps, we need to determine the release series we will run in (we may find that later stages will run in different releases, depending on the evolution of the code, optimization of cuts and pid, etc). We need well a well defined bad-channel map for both detectors, and we need diblock masks for the Far Detector. For generating genie MC, we also need a POT weighted good runs list to accurately simulate running conditions, and a calibration representative of the data sample to be analyzed. This document presents the pre-requisites for both producing a calibration sample, and for producing an analysis sample.
Here we outline the common steps that need to be completed whether producing samples for analysis or for calibration.
- Cut a release branch and first tag (R-tag) for the campaign, as documented in the snapshot and release policy
- Determine the data taking periods (and epochs) for both the FD and the ND. In the case that this includes runs up through an epoch or period where the final run has not been decided, this includes determining what that final run number is for each detector. The production coordinator should then define the corresponding period or epoch dataset definitions and update the Period and Epochs Page (normally the purview of the run-coordinators, who should be notified).
- Bad channels (this is mostly the responsibility of the DQ group; The status of Bad Channels evaluation and validation is reported here)
- Update the bad channels database for all of the runs to be processed or modelled, for both detectors
- Produce a tag for the bad-channels table
- Update ChannelInfo/BadChanList.fcl to reflect the new bad channels tag. For R15-11-17-br series releases and older, there is a single parameter, ValidityTag, that needs to be updated. For more recent releases, there are two parameters: ValidityTagNearDet and ValidityTagFarDet. This is to reflect the fact that there are separate tables for the ND and FD that may fall out of sync. Note that this change must go into the release branch. The production group and release manager should be notified of the new tags.
- The release manager should cut a new patch-release with the updated bad channel tags.
- Check with DQ that the good runs and diblock mask database version is up to date and is the most recent one (see RunHistory/service/RunHistory.fcl).
- The far detector diblock masks(documented here) must be evaluated and uploaded to the DQ database. This is the responsibility of the DQ group. Production processes all data runs whether they are good or bad, so we don't need good runs evaluated for processing data. But as documented below, we do need good run information to generate real conditions MC.
For Calibration¶Here we outline what needs to happen to produce calibration samples. In general, four sets of samples need to be generated:
- FD cosmic ray data
- FD cosmic ray MC (currently we use the CRY generator)
- ND cosmic ray data
- ND cosmic ray MC (currently we use the CRY generator)
The Calibration Group should specify what run ranges need to be processed. In the past, it has been sufficient to process only a subset of the full data sample, especially for the Far Detector. While it is important to get have bad-channels for the processing of the data (and diblock masks for the FD), we normally generate ideal conditions MC. Hence generation of the cosmic ray MC does not need to wait on bad channels or diblock masks. Samples should be processed through the calibration (pclist) chain.
For Analysis¶Here we outline what needs to happen to produce analysis samples. In this case, we generate real-conditions MC, so the bad channel and diblock masks must be evaluated for both processing of data and MC. It's harder to generalize about the samples required, but at a minimum we need to process the following samples through the analysis chain (reco, pid and lem, caf):
- FD NuMI data
- FD neutrino MC (genie)
- FD cosmic ray data
- ND NuMI data
- ND neutrino MC (genie)
Additional samples will be needed for the evaluation of systematic uncertainties and control samples used for studies. In the past this has included both FD and ND genie MC where the calibration has been shifted according to its uncertainty, or variations on the Birks-Chou suppression effect.
- Beam MC requires flux files for the appropriate detector and horn configuration. Note that in the case of the Near Detector, we also need flux files for rock neutrinos. At present the recommended flux files are version 8 (v08), but we don't yet have v08 rock neutrino or horn-off flux files.
- A calibration representative of the analysis sample must be completed, and a corresponding calibration tag produced
- The calibration tag must be propagated to the FCLs in the release branch to be used for generation and processing of the samples. Because the calibration is extracted at multiple stages of the processing chain, this must be updated for all release branches to be used in processing all stages.
- The calibration group should notify the production group and release manager of the new tags. The release manager will cut a new patch-release for
each release-branch updated.
- For both FD and ND, the good runs list is needed to generate real-conditions MC with appropriate POT weighting. So the DQ group must evaluate good runs and produce the appropriate text files, which should be stored at: /nova/app/users/rbpatter/runlists