Project

General

Profile

GENIEHelper Flux

The page further describes GENIEHelper parameters related to neutrino flux.

Flux Drivers

GENIE flux drivers supply the neutrinos that probe the detector. GENIE provides a variety of alternatives that can be selected by setting FluxType to one of:

  • atmo_FLUKA or atmo_BARTOL
    atmospheric fluxes (n.b. ask Brian Rebel about these)
  • histogram
    use a series of histograms to provide the energy spectra for each flavor (n.b. investigate how to configure these)
  • mono
    generate a mono-energetic beam. The MonoEnergy, BeamCenter, BeamDirection and BeamRadius setting are used in this configuration in an obvious fashion.
  • ntuple (via GNuMIFlux)
    use the GENIE GNuMIFlux class to interpret "flux" files (really records of decays of hadrons and muons that yield neutrinos). Details on how to configure this class can be found on the GENIE wiki. Use DetectorLocation: and FluxFiles: to configure this choice.
  • simple_flux (via GSimpleNtpFlux)
    the GSimpleNtpFlux is a simplified ntuple format that could be used for a variety of experiments for flux. At the core each entry is a neutrino ray (flavor, starting point, 4-momentum) with the possibility of a weight and extra information (such as might be used for hadronic re-weighting of the beam simulation). These files can be generated from NuMI simulations (or other beamline simulations that can be coerced into the same format) via GNuMIFlux in order to factorize the flux interpretation from the event generation. Unlike the files used for input to GNuMIFlux these files are for only one particular detector location. Use FluxFiles: to configure this choice (though DetectorLocation: should be set appropriately as well).
    • It is important that users not mix gsimple files that were created with different flux windows and/or different POTs/file; doing so may lead to incorrect overall POT accounting when generating GENIE events.
  • dk2nu (via GDk2NuFlux)
    the GDk2Nu flux driver is similar to GNuMIFlux, but part of the dk2nu project and reads from a more standardized/generalized ntuple format. (note: integration of this driver into GENIEHelper is not yet complete)

Flux File Handling in conjunction with the TTree based driver

The GNuMIFlux, GSimpleNtpFlux and GDk2NuFlux drivers are more complex flux drivers require a set of files containing ROOT TTree's with entries that represent decays yielding neutrinos (ntuple or dk2nu) or individual neutrino rays (simple). Intricacies of how to specify the necessary files, limit the range and determine how they are accessed can be found under Flux File Handling

Choosing neutrino flavors: GenFlavors

This list of PDG codes (12=ν e , 14=ν μ , 16=ν τ , negative for anti-neutrinos) are the only neutrino flavors that will be pulled from the flux driver.

Changing neutrino flavors: MixerConfig

Neutrino flavors can be manipulate between the production by the flux driver and being passed to the event generator driver for evaluation. Currently the only alternative to none is a direct flavor mapping (either in entirety or by fixed fractions) though the GENIE interface supports alternative approaches (i.e. standard oscillations) with the addition of new code.

Setting the MixerConfig string to:

  map 12:16 14:12 -12:-16 -14:-12
would convert ν e → ν τ, ν μ → ν e, and similar for the anti-neutrinos.

Note that the associations are one way. To fully "swap" flavors one must use:

  map 12:14 -12:-14 14:12 -14:-12
The configuration:
  map 12:14 -12:-14
leaves the original ν μ unchanged and so the flavors are not "swapped" as only the ν e flavors get changed. For backward compatibility purposes the term swap is accepted as a synonym for map but is actively discouraged as it mistakenly implies a inverse mapping as well (which isn't the case and never was, and thus was a constant source of confusion). Please modify any .fcl files that use swap to the preferred map keyword.

The fixed fraction specification is a bit more complex. For each input flavor one specifies the fraction that is converted to sterile, ν e, ν μ , ν τ, ν e -bar, ν μ -bar, ν τ -bar. Thus setting the MixerConfig string to:

  fixedfrac  { 14:0.1,0.2,0,0.3,0,0.4,0 }  [... { } ]
means that for ν μ : 10% become sterile, 20% become ν e , 30% become ν τ and 40% become ν μ -bar. The basics grouping is:
    { incoming_flavor : sterile, nu_e, nu_mu, nu_tau, nu_e_bar, nu_mu_bar, nu_tau_bar }
The group must be surrounded by {}'s, the incoming flavor is followed by a :, and the fractions are comma separates (and hopefully other than that white space is irrelevant).

If the mixer needs a distance (i.e. standard oscillations) and the flux generator method doesn't have an interface to supply one (e.g. histogram fluxes, unlike GNuMIFlux and GSimpleNtpFlux which do) then one can set a fixed value using the MixerBaseline.

Where to start the neutrino rays: FluxUpstreamZ

By default the flux driver starts neutrino rays off the flux window. Sometimes that window is positioned incorrectly for a particular geometry, such that one would hope to see events from material upstream of the window. One then needs to tell it to backtrack up the ray to an earlier position (a fixed z in the geometry coordinate system). This should be in flux length units (meters) less than 1.0e30 ... above that it takes as a flag to leave them on the flux window.

    physics.producers.generator.FluxUpstreamZ: -100  # start neutrinos at z=-100 independent of flux window positioning