• Table of contents
• Dk2Nu
  • Documentation
  • Check out the code
  • GENIE FluxDriver interface
  • Referencing code from external projects
    • Primary structures
    • Helper functions
    • GENIE linkage
    • Interactions with the compiler / linker
    • Use in standard GENIE application gevgen_fnal
  • Converting old files
  • A note about weights
  • Other scripts
  • Building the package
    • Building the separate libraries, separately
    • A note about coupling Dk2Nu to GENIE's gevgen_numi in R-2_8_{2,4,6}
  • Administrative nonsense

Dk2Nu¶

The dk2nu ntuple represents one end product of a beamline simulation: hadrons and muons that decay to give neutrinos. As well as a ntuple format, this package will also supply an interface to GENIE so that they may be used in detector simulations.

The long term effort for is for g4numi, flugg and g4lbne to convert to using this format as their "flux" tuples.

Documentation¶

The original proposal can be found here: http://minos-docdb.fnal.gov/cgi-bin/ShowDocument?docid=9070
Documentation of the final result isn't yet available, though reading the code will be informative.

Instructions for accessing additional documentation can be found: here

Tag Release Notes

Check out the code¶

Without read-write privileges:

svn checkout http://cdcvs.fnal.gov/subversion/dk2nu/trunk dk2nu
svn checkout http://cdcvs.fnal.gov/subversion/dk2nu/tags/v01_05_01 dk2nu_v010501

With write access

svn co https://cdcvs.fnal.gov/subversion/dk2nu/tags/v01_01_03 my-dk2nu-svn-checkout 

GENIE FluxDriver interface¶

Configuring the Dk2nu GENIE FluxDriver for use by GENIE currently follows along lines of GNuMIFlux.

Referencing code from external projects¶

Users normally only need to interface with the following classes and functions:

Primary structures¶

source:trunk/dk2nu/tree/dk2nu.h
source:trunk/dk2nu/tree/dkmeta.h

These classes define the two primary trees. The dk2nu records the information about individual decays of hadrons/muons that result in a neutrino. The dkmeta class records meta-data about the corresponding dk2nu tree.

Helper functions¶

source:trunk/dk2nu/tree/readWeightLocations.h
source:trunk/dk2nu/tree/calcLocationWeights.h

The location weight helper functions standardize how calculations are made for the energy and weight of a neutrino ray forced to go through any particular point in space.

GENIE linkage¶

source:trunk/dk2nu/genie/GDk2NuFlux.h
source:trunk/dk2nu/tree/NuChoice.h (used in conjunction w/ GDk2NuFlux)

The GDk2NuFlux conforms to the standard GENIE genie::GFluxI interface. The NuChoice structure allows access to information about the position weight and nu ray info chosen by the driver.

Interactions with the compiler / linker¶

If DK2NU is /path2/to/my-dk2nu-install then use source code would have one or more of:

  #include "dk2nu/tree/dk2nu.h" 
  #include "dk2nu/tree/dkmeta.h" 
  #include "dk2nu/tree/readWeightLocations.h" 
  #include "dk2nu/tree/calcLocationWeights.h" 

  #include "dk2nu/genie/GDk2NuFlux.h" 
  #include "dk2nu/tree/NuChoice.h" 

and the during the compilation phase gcc is passed the flag:

  -I${DK2NU}/include

and during linking one supplies:

  -L${DK2NU}/lib -ldk2nuTree   [ -ldk2nuGenie ]

Use in standard GENIE application gevgen_fnal¶

The GENIE application gevgen_fnal (R-2_9_0 and beyond) will pick up this flux driver automatically if the correct path is added to LD_LIBRARY_PATH.

It is sufficient to first build GENIE and then build Dk2Nu.

For the R-2_8_6 series when the application was gevgen_numi see this node about Dk2Nu and R-2_8_{246}

Converting old files¶

Existing flugg, g4minerava, g4lbne files can be converted to the dk2nu format with some existing scripts.
You should probably do the conversion independent of any particular experiment's setup of code. So from a fresh terminal window:

  # source /nusoft/app/externals/setup
  # setup dk2nu v01_00_00 -q e4:debug
  source /grid/fermiapp/products/nova/externals/setup
  setup dk2nu v01_05_00 -q e9:prof:r5

Assuming you have a flugg style file

  cd /path/to/output/

  # example input file ... pick your own favorite "flugg" file
  export INFILE =/nova/data/flux/flugg/flugg_mn000z200i_20101117.gpcfgrid_lowth/Run001/flugg_mn000z200i_20101117.gpcfgrid_lowth_001.root

  # extract the job# from the filename
  # first strip off path + .root extension
  INFBASE=`basename $INFILE .root`

  # then we want the "job#" which is the last field 
  # right field depend on file name structure ... but generally it is the last ...
  # no leading zeros please because its a number not a string, ROOT wants an int
  export JOBNUM=`echo $INFBASE | tr "_" "\n" | tail -1 | sed -e 's/^0*//' `    

  # for cross check one needs to know if current values are MINOS or NOvA
  # otherwise it will report that the calculation gave wildly different values
  export GENLOC="NOvA"   

  # now do the conversion ... quotes and escaped quotes (backslashes) to make shell happy
  root -b -q $DK2NU/scripts/load_dk2nu.C \
      "$DK2NU/scripts/convert/flugg/convert_flugg.C+(\"$INFILE\",$JOBNUM,\"$GENLOC\")" 

You'll get a warning that it can't write the convert_flugg_C.so to the UPS area, and then it will put it in /tmp/$USER. This should then be followed by output that looks similar to:

  Input file:    /nova/ana/users/rhatcher/flux/flugg/flugg_mn000z200i_20101117.gpcfgrid_lowth_001.root
  Output file: flugg_mn000z200i_20101117.gpcfgrid_lowth_001.dk2nu.root

  7 locations:
   [ 0]  {           0,            0,            0} "random decay" 
   [ 1]  {           0,            0,       104000} "MINOS NearDet" 
   [ 2]  {           0,            0,     7.35e+07} "MINOS FarDet" 
   [ 3]  {      1141.4,       -345.6,      99466.5} "NOvA NearDet" 
   [ 4]  {  1.1129e+06,      -416400,   8.1055e+07} "NOvA FarDet" 
   [ 5]  {        2584,         7842,        74525} "MiniBooNE" 
   [ 6]  {     2881.26,      8139.26,    8.114e+07} "Ash River per Minerva" 

...

Substitute g4minerva or g4lbne for flugg depending on the input file format.

root -b -q $DK2NU/scripts/load_dk2nu.C "$DK2NU/scripts/convert/g4minerva/convert_g4minerva.C+(\"g4numi_NuBeam_me000z200i_0_0001.root\",1)" 

A note about weights¶

Historically the reported weight has been relative to 1 meter radius circle. In the code you'll see a line:

 const double kRDET = 100.0;   // set to flux per 100 cm radius 

Exactly why this convention was chosen is unclear, but it's been there since at least 2002 and in all the variants of the weight calculation (as people keep re-writing it to work in other contexts, PAW, different frameworks w/ the ntuple variables copied to different structures, etc.). When this code was transliterated from FORTRAN to C++ it was carried forward.

At this point the convention is fixed throughout a variety of codes and near impossible to change coherently. sorry

Other scripts¶

root $DK2NU/scripts/load_dk2nu.C $DK2NU/scripts/examples/test_read_locations.C

Building the package¶

  # setup gcc, ROOT (including $ROOTSYS for now), cmake, optionally GENIE
  # if building w/ GENIE,  env var $GENIE must be defined (and exported)
  #   also $LIBXML2_INC ( should have 'libxml' in the pointed directory, with headers under that )
  #   and $LOG4CPP_INC ( should have 'log4cpp' in the directory, with headers under that )

  mkdir -p /path1/to
  cd       /path1/to
  # svn co http://cdcvs.fnal.gov/subversion/dk2nu/trunk/dk2nu my-dk2nu-svn-checkout
  svn co http://cdcvs.fnal.gov/subversion/dk2nu/tags/v01_01_03 my-dk2nu-svn-checkout 
  export DK2NU=/path2/to/my-dk2nu-install
  mkdir -p  $DK2NU
  mkdir -p /path3/to/my-dk2nu-build
  cd       /path3/to/my-dk2nu-build
  cmake [ -DWITH_GENIE=OFF ] -DCMAKE_INSTALL_PREFIX:PATH=/path2/to/my-dk2nu-install \
                      /path1/to/my-dk2nu-svn-checkout
  gmake all install

Building the separate libraries, separately¶

Version v01_06_00 and beyond support building the "data" (ie. tree) and "genie" libraries separately.

For example:

WORKTOP=`pwd`
svn checkout http://cdcvs.fnal.gov/subversion/dk2nu/tags/v01_06_00 source
# gives one the directory source/dk2nu/...

To build that part that becomes "dk2nudata" (i.e. the libdk2nuTree.so library and only ROOT dependence)

cd ${WORKTOP}
mkdir install/dk2nudata
mkdir build/dk2nudata
cd build/dk2nudata

cmake -DWITH_GENIE=OFF \
      -DCMAKE_INSTALL_PREFIX:PATH=${WORKTOP}/install/dk2nudata \
      ${WORKTOP}/source/dk2nu
gmake all install

To build that part that becomes "dk2nugenie" (i.e. the genie libdk2nuGenie.so flux driver library)
which has a GENIE dependence (and its sub-dependences) and a dependence on the previously created dk2nudata build

cd ${WORKTOP}
mkdir install/dk2nugenie
mkdir build/dk2nugenie
cd build/dk2nugenie

cmake -DGENIE_ONLY=ON -DDK2NUDATA_DIR=${WORKTOP}/install/dk2nudata \
      -DCMAKE_INSTALL_PREFIX:PATH=${WORKTOP}/install/dk2nugenie \
      ${WORKTOP}/source/dk2nu
gmake all install

So DK2NUDATA_DIR should point to the location where the previous build installed include and lib

For both one should do the usual with env variables (including PATH, [DY]LD_LIBRARY_PATH, and ROOT_INCLUDE_PATH).
Also the env variable $DK2NU should get set to be the same directory where the include, scripts and etc directories were installed for the dk2nudata half, so that existing scripts can continue to use that.

A note about coupling Dk2Nu to GENIE's gevgen_numi in R-2_8_{2,4,6}¶

This section is relevant only for the R-2_8_X series. The build coupling is no longer present in R-2_9_0 and beyond; simply build GENIE then build Dk2Nu.

NOTE: because interfaces (headers) might have changed do not try to use the same build of Dk2Nu for different versions of GENIE.

The genie stand-alone executable used by FNAL experiments, primarily Minerva, is gevgen_numi. This is built from the source code src/support/numi/EvGen/gNuMIExptEvGen.cxx. Experiments that use GENIEHelper as part of a ART module do not yet have Dk2Nu support.

Currently there is a chicken-and-egg situation for building in Dk2Nu support into gevgen_numi. To build Dk2Nu you have to have already built GENIE proper, and for the gevgen_numi executable itself you have to have already build Dk2Nu w/ GENIE support. The plan was to make this family of flux drivers (GNuMIFlux, GSimpleNtpFlux, GDk2NuFlux) all inherit from a common mix-in (standardized initialization and POT exposure methods) and to have them self-register with a flux driver factory -- which would then break the circular build requirement.

Alas, that didn't happen for this round. So what one must to do is:

• build GENIE sans Dk2Nu in gevgen_numi
• build Dk2Nu w/ GENIE support
• rm $GENIE/bin/gevgen_numi src/support/numi/EvGen/gNuMIExptEvGen.o
• re-build GENIE (should only rebuild gevgen_numi) to get Dk2Nu support in it

This last step requires the env variable DK2NU point at the Dk2Nu installation, i.e. the existence of:

• $DK2NU/include
  • dk2nu/tree/dk2nu.h
  • dk2nu/tree/dkmeta.h
  • dk2nu/tree/NuChoice.h
  • dk2nu/genie/GDk2NuFlux.h
• $DK2NU/lib
  • libdk2nuTree.*
  • libdk2nuGenie*

---

Administrative nonsense¶

tagging dk2nu

---

View wiki structure...View wiki structure...