- Table of contents
- Dk2Nu
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
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
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*