MINOS Mock Data Challenge

Please also refer to the talk given at Ely.

Purpose

The purpose of the MINOS Mock Data Challenge is multifold:

Consolidate our best knowledge into the simulations
Generate a uniform and consistent set of data files that can used in a multitude of analyses.
Produce files to exercise the full analysis
- test of overall framework and data handling
- test both NearDet and FarDet reconstruction chains
Challenge the analysis groups in actually extracting results
- conventional nu_mu to nu_tau signal
- possible nu_e and nu_sterial signals

It is not a test of the calibration chain.

The plan for this Challenge was detailed in my talk (pdf) at the January Cambridge Mtg.

Flux Details

gnumi v16 + GFLUKA to FLUKA reweighting (affects HE tail)
reweight over the face of the detector (& within rock for NearDet)
Challenge set has:
- additional reweighting of hadron production model

Neutrino Physics Details

NEUGEN3
Challenge set has differences in:
- Axial mass for F3 (Quasi-elastic): gv_ma_qel
- Axial mass for F3 (Resonance production): qv_ma_res
- DIS contribution scale factor

Detector Details

Both Detectors

Module-based geometry
- right number of strips/module
- official strip and WLS pigtail lengths
- average clear fiber lengths (for each side of module type and view)
- 0.2mm gaps between strips and 2mm between modules
- (as before) moudles include aluminum skin, but no extra crimp
bypass region is inactive (done in PhotonTransport)

Far Detector

486 steel planes, but no veto shield
correct z spacing (5.949/5.943 vs. 5.94cm) and SM gap
correct coil size; improved average material foam for coil
steel collar (but not seen as magnetized); (? correct inside scint plane?)
extra bypass WLS fiber length accounted for (note: not for NearDet!)

Three FFREAD card files were used for the FarDet: beam, nu_e, nu_tau. The beam file has the nominal beam mixture of nu_e and nu_mu (anti)neutrinos. The nu_e and nu_tau has all the neutrinos converted to that flavor (anti-neutrinos stay anti-neutrinos). The large number of nu_tau files, because of the suppressed cross section, can also serve as a source of additional NC events.

Near Detector

improved hall size (but still not very accurate)
beam x0 = +148.85cm, y0 = +13.97cm at front of steel plane 0

There were two FFREAD card files for NearDet processing: single event generation and the overlay processing. A third (uniniteresting) card file was used to renumber runs and split them into three files.

Statistics and Access

Each FarDet file represents 6.5e20 POTs; NearDet files consist of 550 snarls (spills) each at 2.4e13 POTs/spill.

The files can be accessed either from PNFS (copied out using encp) on machines where PNFS is mounted, or via DCache. The DCache access is most convenient; the base path is dcache:dcap://fndca.fnal.gov:24125/pnfs/fnal.gov/usr/minos/mcout_data/release. The release subdirectory is the minossoft release version; we are currently using R1.7. This is followed by far, near, fmock or nmock as appropriate. Each of these has the subdirectories:

cand_data: These files contain the DaqSnarl (i.e. RawRecord) and Candidate (i.e. CandRecord) streams.
In the case of the non-Challenge (i.e. 'MC') files they also include the SimSnarl (truth) stream
sntp_data: Sue (complete) ntuple files containing NtpSR, Ntp3D TTrees.
In the case of the non-Challenge (i.e. 'MC') files they also include the NtpMC and NtpTH TTrees.
snts_data: Sue (stripped) ntuple files; like sntp_data but with the strip info removed.

The base of the individual files follows the naming convention: <key><ikey><itgt><iflv><S><RRR>_0000

ikey (key)

(N) Near Challenge Data
(F) Far Challenge Data
(n) Near MC
(f) Far MC

itgt

in detector only
in rock only
detector + rock overlayed

iflv

beam
nu_e
nu_tau

The <RRR> represent the random seed sequence used to make the run unique; <S> represent the split (0 for FarDet, 1,2,3 for NearDet).

The files have a final extension of type.release.root where type is cand, sntp or snts.

Thus one can use a command line that looks like:

$ loon myscript.C++ dcache:dcap://fndca.fnal.gov:24125/pnfs/fnal.gov/usr/minos/mcout_data/R1.7/far/cand_data/f24100002_0000.cand.R1.7.root to process a FarDet MC beam flux candidate file.

Det flavor name S RRR exceptions

MC Far beam f2410SRRR_0000 0 001:020

MC Far nu_e f2411SRRR_0000 0 001:009

MC Far nu_tau f2413SRRR_0000 0 001:040 0033

MC Near beam n1430SRRR_0000 1:3 001:100 2007, 3007, 3012, 3014, 3017(?), *021, *025, *027, *029, 3030, *037, *038, *039, *041, 3050, 3054, *065, *069, 2070, 3070, *071, 1078, 2078, *079(?), *082, 1086, 2086, 1087, 2087, 2088, 3088, *089, *090, *091, *092, *093, *094, 3099

"Challenge" Near beam N1130SRRR_0000 1:3 001:100 exception list not yet assembled

"Challenge" Far beam F2110SRRR_0000 0 001:001 a single file representing 7.4e20 POTs.
Do NOT use fm2000001_0000 for anything other than testing purposes. It is NOT the Challenge data!

The exceptions list those files where the GMINOS generation, overlay/splitting or reroot processing failed. Other files may be missing due to problems in the reconstruction processing.

	Det	flavor	name	S	RRR	exceptions
MC	Far	beam	`f2410SRRR_0000`	0	001:020
MC	Far	nu_e	`f2411SRRR_0000`	0	001:009
MC	Far	nu_tau	`f2413SRRR_0000`	0	001:040	0033
MC	Near	beam	`n1430SRRR_0000`	1:3	001:100	2007, 3007, 3012, 3014, 3017(?), 021, 025, 027, 029, 3030, 037, 038, 039, 041, 3050, 3054, 065, 069, 2070, 3070, 071, 1078, 2078, 079(?), 082, 1086, 2086, 1087, 2087, 2088, 3088, 089, 090, 091, 092, 093, *094, 3099
"Challenge"	Near	beam	`N1130SRRR_0000`	1:3	001:100	exception list not yet assembled
"Challenge"	Far	beam	`F2110SRRR_0000`	0	001:001	a single file representing 7.4e20 POTs. Do NOT use fm2000001_0000 for anything other than testing purposes. It is NOT the Challenge data!

Howie's MDC production status page

Notes

Files processed with R1.7

When creating the R1.7 MDC files, a bug existed in the DetSim PMT simulation that casused the Near Detector data to be mis-decalibrated.

Normally, the process to generate ADCs follows:

Charge on channel [fC] = PE x Gain[ADC] * 1.4 fC/ADC (1)
ADC counts = Charge[fC] / 1.4 fC/ADC                 (2)

The first line represents the PMT simulation, which applies the gain, and then converts to charge units. The second line represents the electronics simulation, which converts charge to ADC counts.

The ND files are flawed so that in equation (1), a value of 1.1 fC/ADC was used, but in equation(2) the correct value of 1.4 was used.

This means that the generated files are inconsistent with the calibration tables, and inconsistent between ND and FD. However, the MDC MC and MDC data are consistent with each other.

This will exhibit itself in several ways: Single PEs will have ADC counts ~25% too small. Muons will generate hits with charges 25% too small. Showers too will have total adc counts too small. However, event topologies will be largely unchanged.

Files processed with R1.9

Files processed using R1.9 use the new de/calibration scheme for calculating yields involving the attenuation curves derived from the mapper. The side effect of this is that the simulation of light yield drop off in the last ~10cm of a scintillator strip is no longer simulated. The effect is consistent (i.e. not there for both MDC "Data"a; and MC), but care must be taken when tuning cuts relative to true detector data.

Access to REROOT files

There should be no need for users to access the reroot files. If one wants to disregard the results of the R1.7 reconstruction that's okay, one can still start with the 'cand' files as a source of the RawRecords (and SimSnarlRecords). Actually one probably should not completely disregard the Candidate stream as it makes little sense to redo the CandDigit (i.e. calibration) step.

Contact: Robert Hatcher <rhatcher@fnal.gov>