Documentation:
Terminology:
Job Options Files
Transient Event Store and Converters:
Persistency:
Development:
Here: http://lhcb-comp.web.cern.ch/lhcb-comp/Components/Gaudi_v6/gug.pdf
Here: http://lhcb-comp.web.cern.ch/lhcb-comp/offline/pdf/add.pdf
The mailing list is:
gaudi-developers@listbox.cern.ch
To sign up send mail to:
listserver@listbox.cern.ch
with the single line in the message field
subscribe gaudi-developers firstname lastname <my@email.com>
Back to Top
"...makes use of framework services to perform their work." Each algorithm is called once per event. Implements the IAlgorithm interface, all algorithms used within Gaudi must implement the following three methods: intialize(), execute(), and finalize().
Service are the glue that allows all the pieces of Gaudi to communicate....nothing useful would get done without the services! Gaudi Examples: Message Service, Event Data Service, Tools Service...
Are a special type of algorithm that may be called multiple times per event. Typically, tools would be small algorithms that have some general applicability.
A converter is a specific class that handles the actual conversion of data from its persistent storage representation into an object from a class that is somehow derived from DataObject, so that it may be stored in the Transient Data Store....or converts data from the Data Store into the appropriate representation so that it can be saved to a persistent store.
It is an ASCII file that is used to setup the parameters for a particular run. One can specify the algorithms that should be run, what services to use, number of events, input and output files, etc.
In Gaudi v5 and v6, it appears that environment variables cannot be used within a job options file to define an input parameter. The only way one can use an environment variable is to specify an include file for a given job options file.
However, we have provided a mechanism to resolve environment variables, so that they can be used as input parameters.
How do I specify a path and file name in a job options file ?
Sometimes we may want to access parameters that are already available to an existing algorithm or service. We can obtain the value for these parameters as shown in the following code:
IProperty* appPropMgr=0;
// retrieve a pointer to the ApplicationMgr, who has the parameter we want to obtain
StatusCode status = serviceLocator()->getService("ApplicationMgr", IID_IProperty,
reinterpret_cast<IInterface*&>( appPropMgr ));
if( status.isFailure() ) return;
// Declare our property type, and set it to zero
IntegerProperty evtMax("EvtMax",0);
status = appPropMgr->getProperty( &evtMax ); /// retrieve the data
In a nutshell, the Transient Event Store is a mechanism for shared memory. It is a tree that stores all data pertinent to a particular execution of the code. All algorithms, services, tools, etc, within Gaudi use the data store to both retrieve the data needed to do its particular task, and to store any output data. The data store only exists while a program is executing - data is saved for later use via the Persistency Service...but that's another story. For more detailed information, see Chapter 6 in the Gaudi v6 User's Guide and Chapter 9 in the Architecture Design Document.
There are 2 main ways...either data is created within an algorithm, and is stored in the Transient Event Store via some call to registerObject() or some piece of code makes a request for some data. The request is performed by a call to findObject() or retrieveObject() - or through the use of a SmartPointer. When a request is made, first the Transient Event Store is checked to see if the data is already available - if so that's great and it passed to the requestor. If the data is not available...then the Persistency Service is called and an appropriate Converter is used to retrieve the data from a persistent store, probably some file somewhere. There is some magic going on in the background - usage of OpaqueAddresses so that proper converter is called....we'll ignore that for now. The converter's createObj() method is called which allocates the necessary space, and then a call to updateObj() retrieves the data and stores it in an object derived from Gaudi's DataObject class - only objects derived from a DataObject (or one of Gaudi's ObjectContainers, see section 6.4 in the Gaudi user's guide) can be stored in the Transient Event Store.
With care :)
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.
where PDS == Persistent Data Store See this discussion on using the PDS.
This requires some steps that are not written down in the Gaudi Manual. Do put an object into the TDS you need to have retrieved each branch of the TDS before your particular object. Say you want to register an object at /Event/Raw/Foo, you need to retrieve all the /Event and /Event/Raw first. Here is the code to register /Event/Raw/Foo from any algorithm:
DataObject* pnode=0; // check to see if branch is there sc = eventSvc()->retrieveObject("/Event", pnode); if(sc.isFailure()) { log << MSG::ERROR << "Could not retrieve Event directory" << endreq; return sc; } //check the sub directory sc = eventSvc()->retrieveObject( "/Event/Raw", pnode ); if( sc.isFailure() ) { //create the new sub directory if couldn't retrieve it. sc = eventSvc()->registerObject("/Event/TkrRecon",new DataObject); if( sc.isFailure() ) { log << MSG::ERROR << "Could not create Raw directory" << endreq; return sc; } }
sc = eventSvc()->registerObject("/Event/Raw/Foo", m_foo);
This is not a very nice way of doing things. I'm certain that things will change
in the future.
Debugging the Gaudi apps is somewhat tricky because Visual Studio disables all the break points you set within the code that is going to be linked into a DLL. Therefore you need to step into the app past the configure stage before you can re-enable your break points. Currently (02/20/2001) 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.
Macro Listing:
Sub stepdll() 'DESCRIPTION: this steps into the area where the dll is loaded 'Begin Recording ExecuteCommand "DebugStepInto" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugStepInto" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugStepInto" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugStepOver" ExecuteCommand "DebugBreakpoints" 'End Recording End Sub
Text file containing the macro: DebugMacro.txt