Project

General

Profile

Generating Neutrino Events in the Rock

There is early discussion of some of the issues involved in generating neutrino events in the NOvA rock in the 2012-04-19 Collaboration talk: NOvA-DocDB-7291

GENIE volume selector

One important key to efficient generation is to limit the consideration of potential locations for events in the rock. The chosen strategy is to trim the volume upstream of the detector enclosure depending on the direction and energy of individual neutrino rays. The details of how to specify this are documented on the page: GENIEHelper Geometry (scroll down to "Special case: RockBox FiducialCut strings")

This "rockbox" improves the efficiency of choosing GENIE vertices at the level that GENIE can choose them before it decides on kinematics. As I've previously said, this makes the conservative assumption that any given interaction could put all the neutrino's energy into the muon and allows for that vertex to be chosen such that it just trickles into the defined box. That is what it uses to limit where it considers interactions to potentially occur. Once that is defined GENIE can then decide whether an interaction did happen from the neutrino ray under consideration. If it decides yes, then it also picks the nucleus type, a vertex and the event kinematics (QE/Res/DIS, x_bj, y_by, etc). The code we have in hand does not perform the additional optimization(s) that can be made after the interaction is defined.

Example .fcl additions

physics.producers.generator.FiducialCut:   "rockbox:(-266.7,-230.08,-411.48)(266.7,257.6,1630.68),0,800,4.4732e-3,1.10" 
physics.producers.generator.TopVolume:     "vWorld" 
physics.producers.generator.FluxUpstreamZ: -100000
physics.producers.generator.ZCutOff:        100000

##  ... estimating the maximum path length is apparently hard in the case of rock generation
##  suggest the values get bumped.   Until standard files are available, and/or the flux method
##  gets fixed so that it doesn't screw up POTs accounting, use the box method with a inflated
##  fudge factor (normally 1.1)
physics.producers.generator.GeomScan:     "flux: 10000 1.2 1" 
# physics.producers.generator.GeomScan:     "file: maxpathlength_ndrock.xml" 
#physics.producers.generator.GeomScan:     "box: 200 200 1.2" 

Issues

  1. Our geometries initially didn't have enough rock below (NDOS,NearDet,FarDet) or above (NearDet) for proper rock generation. This limited how far upstream and/or below(above) one would see events. This should now have been corrected (circa 2012-06-29), but a confirmation that it is sufficient would be useful.
  2. To properly do this we need a flux with a wider flux window; Jobs to do this have been submitted, though they may still require futher adjustments to the width. In the meantime continue to use the existing flux files that are more suitable for detector-only event generation. The bulk of the events are inline w/ the detector so the wider window isn't critical for an initial start. A limited number and selection of files have been made available, and can be set using a line like:
    physics.producers.generator.FluxFiles: [ "flux/gsimple/nova_v03/fdrock/mn/fhc/*.root" ]
    The available combinations are:
    • fdrock/mn/fhc
    • ndrock/mn/fhc
    • ndosrock/mn/fhc
    • ndosrock/le/fhc
    • ndosrock/le/rhc
  3. In choosing the (x,y,z) min/max for the "rockbox" configuration pick global coordinates just inside the hall up snug against the rock/walls and not tight against the detector. Ideally the geometry would have nothing in the vDetEnclosure beyond the basic detector (i.e. include bookends, but not bits of rock); this now (as of 2012-07-??) seems to be the case. Suggested box extent values for rockbox:(xmin,ymin,zmin)(xmax,ymax,zmax),0,800,4.4732e-3,1.10 (as of 2012-07-17) are:
    • ( -304.8000, -196.6350, -464.8200 ) ( 304.8000, 382.485, 1821.1800 ) neardet-3x3-6block-xtru-vacuum.gdml
    • ( -890.2598, -782.3500, -0.0000 ) ( 1029.9802, 1285.1998, 8473.4400 ) fardet-12x12-30block-xtru-vacuum.gdml
    • ( -596.9000, -196.8150, -177.0888 ) ( 596.9000, 443.2650, 1707.1848 ) ndos-2x3-6block-xtru-vacuum.gdml
  1. The de/dx parameter (GeV/geometry-length, e.g. GeV/cm) is a crude approximation. Looking in the PDG book about bulk material properties for "standard rock" for the de/dx (in MeV*g/cm^3) and density and doing the calculation yields this a value of 4.4732e-3.
  2. You should definitely explicitly set
       physics.producers.generator.TopVolume: "vWorld"

    This is apparently the cause of the unexplained z-offset reported in DocDB-2791. This some weird interplay between GENIE, GENIEHelper and the rock selector code.
  3. You should also have a line similar to:
        physics.producers.generator.FluxUpstreamZ: -100000

    By default the flux driver continues to start neutrino rays off the flux window (which we have at z = -5m I believe). So you need to tell it to backtrack up the ray to an earlier position. This should be in flux length units (meters). If you set it at least as far upstream as your rock box will ever extend then you won't lose events from that. As long as the abs(value) is less than 1.0e30 ... above that it takes as a flag to leave them on the flux window.
  4. To avoid GENIEHelper "helpfully" throwing aways some events one should also use:
        physics.producers.generator.ZCutOff:      100000
    to avoid it tossing downstream events.
  5. There are reports of GENIE failures of the form:
    1342065151 FATAL GMCJDriver : [n] <GMCJDriver.cxx::GenerateEvent1Try (886)> : Negative no interactin probability! (P = -11.3875 %)
    after which GENIE simply shuts down the program. These are due to a mis-estimation of the maximum path length of material. The suggested solution is to artificially inflate the estimated maximum pathlength from the geometry scan. This can be done using the fcl parameter:
     physics.producers.generator.GeomScan:     "flux: 10000 1.2 1"
    If the problem continues at an unacceptable level then one can further push the scale factor beyond 1.2 (default is 1.1).
  6. The use of GeomScan: box (the default unless otherwise explicitly set to "flux" or "file") is nonsensical for use with the rock box because that method scans the geometry with effectively no spectrum and thus the box can not respond by expanding. Due to how ray directions are chosen the effective energy of the rays will always be 1.0 GeV.

MINOS also prevented (some) final state particles from being propagated by GEANT if they were too far away from the box. Later optimizations also had hooks into GEANT user actions so that tracking in the rock was more coarse (larger cuts by tweaking the tracking medium), and ParticleTransportSim could also be configured to kill off secondaries and such from the final state that were deemed too wimpy to reach the hall.