The Gaudi Developer Guide Section 4.4 Configuring the job and Section 11.3 The Job Options Service provide additional Gaudi-specific details about jobOptions files.
Debugging
Windows
Debugging the Gaudi apps is somewhat tricky because in Visual C++ disables all the break points set within the code that is part of a shared library (DLL). Therefore you need to step into the application past the configure stage before you can re-enable your break points. Currently the best procedure for doing this is as follows.
- Set a breakpoint in your main program at the line:
- status = appMgr->run();
- Step into until you pass "sc = configure( );" in the Application manager.
- Now set your breakpoints
There is also a macro available that will step past the configure line in the Application manager and pop up the breakpoint window if you start while at the "status = appMgr->run():" line.
See Accessing Gaudi Services for a list of all available services.
The Glast Gaudi Guide is meant to provide an introduction to Gaudi and its use with the GLAST
What makes Gaudi Special?
There are a number of useful features of Gaudi, here is a list of some of them:
Acronyms and Terms
ACD Anti-Coincidence Detector abstract interface A class that only declares a set of methods without any definitions. The definitions are left to those classes that derive from the abstract class. CAL Calorimeter CMT Code Management Tool CVS Concurrent Versions System component In the Gaudi sense, refers to a block of software with a well defined interface and purpose. ex.) an algorithm or a service Doxygen Tool used to automatically generate code documentation. Gaudi Object Oriented Framework used to structure our simulation and reconstruction code. ROOT An I/O library and analysis framework TDS Transient Data Store TKR Tracker VCMT Visual Code Management Tool - a GLAST developed tool that provides a GUI interface on top of CMT on Windows.
To install Gaudi on your local machine, you must use CVS/CMT to download the source and compile the libraries. Please see the instructions available on the GLAST Gaudi v9 home page:http://www-glast.slac.stanford.edu/software/gaudi/gaudi_v9/.
The jobOptions file is an ASCII file that is used to setup the parameters for a particular run. One can specify the algorithms to execute, what services to use, number of events to process, input and output files, etc. All applications that use Gaudi currently require a jobOptions file. The jobOptions parameters determine:
Most components that are used with Gaudi are available within shared libraries. Users must inform Gaudi which shared libraries we wish to load. This can be done using a line like:
ApplicationMgr.DLLs = { "TkrRecon", "CalRecon" };
This will tell Gaudi to load these 2 libraries.
One could also add an additional library to the list via a line like:
ApplicationMgr.DLLs += { "AcdRecon" };
Many of Gaudi's default services - like the MsgSvc are loaded and set up automatically. Others must be requested explicitly. This is done through a line like:
ApplicationMgr.ExtSvc = { "GlastEventSelector/EventSelector" , "EventCnvSvc" };
Again, as in the "Loading shared libraries", one could add additional services via a line like:
ApplicationMgr.ExtSvc += { "GrbSvc" };
Users must inform Gaudi which algorithms to execute, and in what order.
ApplicationMgr.TopAlg = { "MyAlg", "AnotherAlg" };
In this example, MyAlg would be executed first, followed by AnotherAlg. The order of execution is determined by the order the algorithms appear in this list.
A note about Sequencer statements
A set of algorithms can be grouped together and given a name.
Debug, Informative, warning, and error messages can be written out when running a Gaudi job. Users specify the priority level of output they desire:
2=DEBUG, 3=INFO, 4=WARNING, 5=ERROR, 6=FATAL
MessageSvc.OutputLevel = 2;
Additionally, the output level for individual algorithms may be set, via a line like:
MyAlg.OutputLevel = 3;
For more information about Gaudi's Message Service please see the Gaudi Provided Service section of this guide.
Many Gaudi default Gaudi services and GLAST-defined algorithms and services accept input parameters.
The parameters that our GLAST-defined algorithms and services accept will be available in the mainpage description of each GLAST package.
Here is a link to a very simple jobOptions.txt file.
The Gaudi Developer Guide Section 4.4 Configuring the job and Section 11.3 The Job Options Service provide additional Gaudi-specific details about jobOptions files.
There are a number of GLAST-specific jobOptions. It is currently mandated that each GLAST package describe the jobOptions parameters it defines in its Doxygen mainpage. This is a work in progress, however, users are encouraged to look to the mainpages as a source of detailed information of GLAST defined jobOptions parameters.
Without going into the details of all possible jobOptions parameters available, we will now discuss the minimum jobOptions parameters necessary to use the Gaudi TDS. The following must be present:
Load the GlastSvc library - which contains our GlastEventSelector and EventCnvSvc.
ApplicationMgr.DLLs = { "GlastSvc"};
To use the TDS, we must have an EventSelector and a set of conversion services. We have defined a GLAST EventSelector - called GlastEventSelector and a set of GLAST conversion services provided by the EventCnvSvc.
ApplicationMgr.ExtSvc = {
"GlastEventSelector/EventSelector" ,
"EventCnvSvc" };
The set of GLAST conversion services should be made available to the Gaudi persistency service.
EventPersistencySvc.CnvServices = {"EventCnvSvc"};\
No input is required for the EventSelector, rather, data will be acquired either through a Monte Carlo generator or via ROOT files. Additional parameters will be required to setup an MC generator or to activate ROOT input.
EventSelector.Input = "NONE";
One of the advantages of Gaudi is its ability to dynamically load shared libraries, on all of our supported operating systems. To use this feature, we must adhere to some simple guidelines.
First, in the requirements file for our package, we must define a library and use some special patterns defined by the GaudiPolicy package:
# Use this pattern for shareable libraries that Gaudi must load
apply_pattern packageShr
library HelloWorldGaudi HelloWorld.cxx Dll/*.cxx
private
# Flags for building shared libraries
apply_pattern package_Cshlibflags
Each of our packages which contain Gaudi components creates a shareable library that Gaudi recognizes. Each such package requires 2 special source files:
<packageName>_dll.cxx and <packageName>_load.cxx. These files are used by Gaudi to load the shareable libraries at runtime. These files, according to GLAST SAS convention, are stored in a directory called: src/Dll.
Gaudi now provides standard macros that define all of the required pieces. In effect, we just have to fill in the blanks.
There are 2 required components:
An include file and a macro where we supply the name of the package.
Here is an example from the GlastSvc package:
#include "GaudiKernel/LoadFactoryEntries.h"
LOAD_FACTORY_ENTRIES(GlastSvc)
There are 2 required components. An include file:
#include "GaudiKernel/DeclareFactoryEntries.h"
and a method named:
DECLARE_FACTORY_ENTRIES(<packageName>)
The method contains declarations for each Gaudi algorithm, service, converter, converter service, tool, etc.. All possibilities are defined in the DeclareFactoryEntries.h file. Here are the most common:
DECLARE_ALGORITHM(x)
DECLARE_ALGTOOL(x)
DECLARE_AUDITOR(x)
DECLARE_CONVERTER(x)
DECLARE_GENERIC_CONVERTER(x)
DECLARE_OBJECT(x)
DECLARE_SERVICE(x)
DECLARE_TOOL(x)
Here is an example from the GuiSvc package:
#include "GaudiKernel/DeclareFactoryEntries.h"
DECLARE_FACTORY_ENTRIES(GuiSvc) {
DECLARE_SERVICE( GuiSvc);
}
That is it!
Now you just need to compile the code and setup the jobOptions file to load the shareable library and to use the algorithm, service, etc that you have defined. For example, if the new sharable library was called HelloWorldGaudi and you had added a new algorithm called HelloWorld, you would add the following to your jobOptions file:
ApplicationMgr.DLLs += {"HelloWorldGaudi"};
ApplicationMgr.TopAlg += { "HelloWorld" };
Other sections of Heather's Gaudi Guide re: Service:
Every Gaudi Algorithm has a method available called toolSvc( ) which provides an easy mechanism to access tools.
ImyToolInterface *m_tool;
sc = toolSvc()->retrieveTool("myToolName", m_tool);
if (sc.isFailure() ) {
log << MSG::ERROR << " Unable to create myToolName tool" << endreq;
return sc;
}
What is persistency? To put it simply...storing data to be used later. The idea is that the data exists after a particular run is finished. We are currently using ROOT files to store our data, however, any I/O library could be used if we set up the appropriate interface.
Gaudi provides the Persistent Data Service (PDS) to save and retrieve data for later use. This service performs two primary functions:
All data that is on the Transient Data Store (TDS) is deleted at the end of each event. A user may specify that some of the data should be stored as output. When a user makes such a request, Gaudi uses its Persistent Data Service to orchestrate the writing of the data.
While running a job, all requests for data are processed through the TDS. If the data is not available on the TDS, the Persistent Data Service is used to retrieve the data from a file or database.
When the Persistent Data Service receives a request to read or write data, the appropriate converter is called that actually handles the details.
What is a converter? It is a simple class that handles the actual conversion of data from its transient representation to its persistent representation. Each converter derives from Gaudi's abstract class IConverter.
http://proj-gaudi.web.cern.ch/proj-gaudi/Doxygen/v10r0/doc/html/class_i_converter.html
There are some details involved in setting up the mechanism for the persistency service to find the appropriate converter to call - basically each converter is registered with the persistency service so the converter can be found at run time.
Figure taken from the Gaudi Developer Guide, Chapter 13
Gaudi Developer Guide Chapter 13 Converters
M.Frank et al., Data Persistency Solution for LHCb, [Proc CHEP 2000], http://cern.ch/lhcb-comp/General/Publications/pap-c153.pdf
ROOT is one of the Gaudi supported I/O libraries. However, currently, we are not using the Gaudi PDS to write our ROOT files. Why? The ROOT files generated using the default Gaudi PDS ROOT I/O do not contain the structure of the objects - basically a bit stream is written to the ROOT files. So while the file is indeed a ROOT file, one could not sensibly take that file and analyze the contents in ROOT - at least not easily.
For more details, please see this old talk from a GLAST SAS workshop:
http://www-glast.slac.stanford.edu/software/reviews/core/jan2001/rootio.pdf
Currently, we do write and read ROOT files. We do this through simple Gaudi algorithms that are called at the beginning (for reading) or at the end (for writing) of each event. Data is taken or put on the TDS and written or read from the proper ROOT files. The algorithms are located in our RootIo package.
The problem with this approach is that is not flexible. We are not taking advantage of the I/O interface that Gaudi has already provided. Users have no control over precisely what is written or read. Users may choose that Monte Carlo, digitization and/or reconstruction data is read/written, but there is no way to specify a subset of those categories. For example, if writing a reconstruction ROOT file, there is no way to write out just the tracks from the TKR reconstruction - rather you would be forced to write a file containing all the TkrRecon data as well as all CAL and ACD reconstruction data as well.
We are very interested in supporting real ROOT I/O within the default Gaudi Persistency Service. Over the coming months, we will be working to develop an interface between the Gaudi Persistency Service and real ROOT I/O.
We are not the only ones interested in using real ROOT I/O with Gaudi. There is a group at Brookhaven National Lab that is developing their own ROOT persistency service.
http://www.usatlas.bnl.gov/computing/software/db/rootio.html
Debugging the Gaudi apps is somewhat tricky because in Visual C++ disables all the break points set within the code that is part of a shared library (DLL). Therefore you need to step into the application past the configure stage before you can re-enable your break points. Currently the best procedure for doing this is as follows.
There is also a macro available that will step past the configure line in the Application manager and pop up the breakpoint window if you start while at the "status = appMgr->run():" line.
???link to 2002 Glast Gaudi Home: http://hepg.sdu.edu.cn/zhangxueyao/Gaudi/gaudi/default.htm