Here are some answers to Frequently Asked Questions about pdrApp.
pdrApp is a checkout package. By checking out this package, you will obtain all of the packages to run the simulation - including all of the Gaudi code and our Glast specific code, including our reconstruction algorithms. But you are encouraged to first check out GaudiSys v7 and gismosys (currently v4r3) into separate folders in the CMT path. These change much less often, and then don't have to be rebuilt.
pdrApp is also an application built by the package that depends on all the packages necessary to build itself. Thus by making the app, pdrApp, you can make all dependent packages at once.
userAlg is a regular package. It contains one simple Gaudi algorithm, named UserAlg, and builds an application containing it called userApp. The algorithm provides examples of accessing data from Gaudi's Transient Data Store and how to store quantities in a Root ntuple. To use this package, one must also checkout pdrApp. Since userAlg depends on pdrApp, making userApp makes all dependent packages. The jobOptions.txt file that comes with it has an #include for pdrApp, to which it adds UserAlg as a top-level algorithm, and repeats
Currently, the output from pdrApp consists of a Root ntuple. A new page will be constructed that will list the current names of all ntuple elements. Want to know how to read the ntuple into Root?
You may obtain a binary distribution of pdrApp for Windows or Linux from:
http://www.slac.stanford.edu/exp/glast/ground/software/Releases/
userApp is a package, that uses pdrApp. First checkout a copy of pdrApp, then checkout userAlg. Obtaining the code is fairly straightforward. Follow the directions supplied in our helpful Code How To page.
First, it should be noted that general users should not have to modify the
compiler settings. However, if for some reason you need to do so:
The package GlastPolicy is used to setup the compiler and linker options for
the build. You will notice that the GlastPolicy package does not consist
of much more than the requirements file. It is within the requirements
file, that the compiler and linker options are setup. If for some reason,
you desire to modify the compiler/linker settings, modify your local copy of
GlastPolicy's requirements file.
This is due to ROOT not being found on your system. You either:
Need to install ROOT. See
this page in the GLAST How-To Guide.
OR
Need to be sure that the requirements file for EXTLIB is setup to point at your
ROOT installation. Please note that if you did not install ROOT within
your GLASTEXT directory - then you will certainly need to modify the EXTLIB
requirements file.
This can be done using the jobOptions file. This one of the nice
features of Gaudi, they provided a message service. The output level is
controlled by the following line in the job options file:
// Set output level threshold (2=DEBUG, 3=INFO, 4=WARNING, 5=ERROR, 6=FATAL )
MessageSvc.OutputLevel = 3;
To reduce the amount of text, increase the OutputLevel.
This is true of ALL applications that run using Gaudi.
See the file called source_library.xml. This file resides in the flux package under the xml directory.
The jobOptions have now been split up into separate text files:
jobOptions.txt - this is the file that is called when running
pdrApp, all other files, to be included in the setup, must be included in this
file.
basic.txt - core set of options required to perform a run of
pdrApp
montecarlo.txt - set up to use the monte carlo generator to
produce events
display.txt - sets up the Event Display
read_irf.txt - setup to read in an existing IRF file
write_irf.txt - setup to write an IRF file
recon_root.txt - setup to write a Recon ROOT tree file
The pdrApp main program uses an environment variable JOBOPTIONS to determine the name and location for a jobOptions file.
This is set in the jobOptions file, via the ApplicationMgr.EvtMax parameter.
By default, pdrApp will run with the same random number seed no matter how
many times your run it - generating the same events each time. We use
CLHEP's random number generator. The default seed is 9876. You can provide
a different random number seed by adding the following to your jobOptions file:
GismoGenerator.randomSeed = 54321;
It is recommended to choose seeds that are listed in the SeedTable.h file included with the CLHEP library.
To set the run number to be 496, add the following line to your jobOptions
file:
GismoGenerator.run_number = 496;
If running userAlg, copy ApplicationMgr.ExtSvc section from pdrApp's jobOptions file, and insert it into the jobOptions file in the userAlg directory. Then remove the reference to "GuiSvc".
If running pdrApp, open the jobOptions file and remove the reference to "GuiSvc" from the ApplicationMgr.ExtSvc section.
Or comment out the line containing GuiSvc in later versions of the standard jobOptions files.
Here are the steps:
The L1T mask determines what events are written out to the output files (IRF,
ROOT ntuple and ROOT Recon Tree file). By default, all events are written
to output - whether or not they passed any trigger criteria. If one
desires to modify this behavior, one must add the following line to the
jobOptions.txt file:
L1T.mask = 0x00000004;
This will set the L1T mask, such that only events that pass the 3-in-row in the
TKR criteria will be written to output.
pdrApp will output some, all, or none of the following, depending up the job
options that are setup in your jobOptions file:
an IRF file, Root ntuple, and a Root Recon Tree file.
The IRF contains the detector data.
The ROOT ntuple contains the summary event information, including Monte Carlo
data concerning the incident particle, and some reconstruction quantities useful
for background rejection.
The ROOT Recon Tree file contains detailed reconstruction results - including
the tracks found by the TkrRecon.
Include the write_irf.txt in jobOptions.txt file and then add a line like this to the jobOptions.txt file:
GismoGenerator.output_file="/data/vertical_muons.irf";
Modify the jobOptions.txt file as follows:
add:
#include "$PDRAPPROOT/src/read_irf.txt"
remove or comment out:
#include "$PDRAPPROOT/src/basic.txt"
#include "$PDRAPPROOT/src/montecarlo.txt"
#include "$PDRAPPROOT/src/display.txt"
specify the IRF file you wish to read in:
EventSelector.Input = "IRFFILE $(INSTRUMENTROOT)/src/test/muontest.irf";
Note: Starting with pdrApp v6r4, we now have a new IRF format that includes Monte Carlo particle data. For now, it appears that this is not backwards compatible with the old IRF format. This version of pdrApp will not run with older IRF files.
Here is an example of how to read the Root ntuple in Root.
The merit package came with your pdrApp distribution. This program is designed to read in an input Root ntuple and perform a series of standard cuts to the data - producing some nicely formatted output, describing the result of cuts, the event that pass the trigger criteria, and the resulting PSF and effective area.
To run merit, do the following:
Windows/VCMT:
Select "merit" in the VCMT package window.
Select "meritapp" in the Project drop down list.
In the parameters text box input something like: -1rb pdr.root
Here the string -1rb means to apply the level 1 trigger filter, the resolution
cuts and the Ritz background rejection cuts.
Linux from the command line
Source the setup.csh file for the merit package, to setup your environment
Run merit from the command line: meritapp.exe -1rb pdr.root
To read the Recon Root Tree file - you should use ROOT. You will need the a shareable library (reconRootData.dll for windows or reconRootData.so for UNIX) containing the definitions of the classes for those objects stored in the file. The pre-compiled library is available for download. See this page. You should always download the most recent version of the root class libraries...currently the file to download is v5 this contains digiRootData v2r6 and reconRootData v2. reconRootData v2 should be the final version to be used for the PDR.
Then before you open the root file in an interactive ROOT session, do the
following:
gSystem->Load("reconRootData.so");
Please see the GLAST ROOT FAQ.
The UserAlg algorithm is typically executed at the end of an event, after all of the other data processing algorithms have be called, including the reconstruction routines. All data that is meant to be shared among the algorithms is placed on Gaudi's Transient Data Store (TDS).
Here is a list of items that are currently available from the TDS.
The ntuple is stored in the Transient Data Store (TDS). The ntupleWriterSvc provides a method that will retrieve the ntuple from the TDS given the ntuple's name, such as "PDR". Once you have the ntuple, you can then access the data. Please note, that the contents of the ntuple are of type NTuple::Item<float> - see the definition of the acd_doca variable in the following code snippet.
In your UserAlg::execute routine, insert the following code, where your can modify it to access the ntuple variables of interest to you:
SmartDataPtr<NTuple::Tuple> nt = m_ntupleWriteSvc->getNTuple(m_tupleName.c_str());
if (nt) {
log << MSG::INFO << "retrieved Ntuple " << endreq;
NTuple::Item<float> acd_doca, tkr_no_tracks;
if ( (nt->item("ACD_DOCA", acd_doca)).isFailure(
) ) {
log << MSG::INFO << "didn't retrieve acd_doca" << endreq;
} else {
log << MSG::INFO << "ACD_DOCA = " << acd_doca <<
endreq;
}
}
Please note that when accessing the ntuple variables - be sure to use the correct tag names (and capitalization) as specified in the ntuple description. If an event is not written the ntuple (due to not triggering, for example), the the ntuple quantities retrieved will be zeros.