 |
ATLAS Offline Software
|
|
ATLAS Offline Software
|
RegistrationServices is a package containing services for different database-related registrations. Currently there are three services:
All of these services are documented below.
Whenever an AthenaOutputStream writes out an event, there is always a DataHeader object written which contains references to all other DataObjects written out in the event. As well, a DataHeader may contain one or more references to events written in a previous processing step. This allows, for example, navigation from AOD to ESD to RAW data. Note that the references are implemented as POOL tokens which are globally unique ids as character strings.
RegistrationStreams write out Event Collections. Event Collections are lists of references to DataHeader's ('events') and any associated metadata (called a 'Tag') that the creator has accumulated and associated with the reference using an (Athena)AttributeList. The Event Collection may then be used to select events according to the Tag values and then make sub-collections and/or navigate to the events.
A RegistrationStream has the following settable properties.
Athena supports several predefined sequences AthAlgSeq, AthOutSeq, and AthRegSeq. RegistrationStreams should be placed in the RegSeq to make sure they follow the data output streams.
Multiple RegistrationStreams may be used. Each RegistrationStream has a Tool which writes to a separate collection. Using the fact that a RegistrationStream is also a FilteredAlgorithm one can add corresponding selection criteria to decide whether each event being processed should be registered or not. The selection is done by one or more algorithm which has run before the RegistrationStream. The selection algorithm uses:
/// Set the filter passed flag to the specified state virtual StatusCode setFilterPassed( bool state );
to set/unset its filter flag. A RegistrationStream may have one or more algorithms as filters, and the filters may be one of three types:
If there are no filter algorithms, then all events are accepted. Otherwise an event is accepted if it has at least one Accept alg AND ALL Required algs AND NO Veto algs with filterPassed set to true.
The RegistrationStream communicates with its Tool using the IRegistrationStreamTool interface defined in AthenaKernel. The Tools used by the RegistrationStream can look for different classes in StoreGate as Input. The Tool makes this available to the RegistrationStream through its listID() method. The Tool also contains the code that is "persistency" specific. The current Tools are listed below.
The ItemList is used for three different, but related purposes.
The IOVRegistrationSvc is used used to register conditions objects in the Interval of Validity (IOV) database. We consider two steps for the storing of conditions data. The first step writes out the conditions data itself, and the second step registers the data with an IOV in the IOV DB. This service currently provides only for the second step, although it is envisaged to allow one to optionally integrate the first step so that the service can provide a single step operation when desired.
The service is accessed via its interface, IIOVRegistrationSvc, which provides a number of registerIOV methods. To register an object one must provide the following information, where options are indicated:
The IOVRegistrationSvc service has the following properties:
Note that the BeginTime and EndTime are specified in seconds since 00:00 GMT on 1st January 1970, and not in nanoseconds as used internally by COOL.
There are a number of registerIOV methods of the IOVRegistrationSvc service which allow different combination of optional arguments, and as well to use the IOV as specified by the job options. Note that the ones specifying timestamps use full 64 bit timestamps (in nanoseconds since 1/1/1970, and not seconds as in the job options).
Normally when one registers a new IOV, the minimum corresponds to the beginning of the new interval of interest one leaves the maximum at infinity. Each insertion will thus redefine the interval maximum of the previous IOV whose max was at infinity. For example, one might add intervals as (run,LB):
This will register IOVs for run 2590, 2591-2, and 2593+.
In special cases, there IS a GOTCHA that one must take into consideration. This is the case where one wants to insert an exact interval with the max NOT at infinity. In this case the max MUST be +1 larger than the desired interval. For example, if one wants to add in a special interval for run 2592 LBs 7 to 15 inclusively, then one would add the IOV:
An implication of this logic is that as one keeps registering new IOVs using max at infinity, the IOVDb actually sets the max of the previous IOV to be equal to the min of the new IOV. That is IOV maximum values are considered to NOT be included in the interval of validity, sometimes referred as [min1, max1), [min2, max2), where '[' == "inclusive limit" and ')' == "exclusive limit" and thus max1 == min2.
Athena users define inline COOL data objects as AthenaAttributeLists and CondAttrListCollections, which use coral::AttributeListSpecification to define the data types. In COOL 2.0, the mapping between these transient data types and the persistent COOL database types is not unique (for example transient std::strings can map to COOL String<x> types of different length: 255, 4k, 64k and 16M CLOB strings. Two job option parameters OverrideNames and OverrideTypes can be used to customise this mapping. For example, consider a transient coral::AttributeList containing two strings named SmallString and BigString, and defined on the transient side as:
coral::AttributeListSpecification* attrSpec = new coral::AttributeListSpecification();
attrSpec->extend("SmallString", "string");
attrSpec->extend("LargeString", "string");
AthenaAttributeList* attrList = new AthenaAttributeList(*attrSpec);
The first time this AthenaAttributeList gets stored into COOL using the IOVRegistrationSvc, the desired COOL types can be specified with the job options:
IOVRegistrationSvc.OverrideNames+=['SmallString','LargeString'] IOVRegistrationSvc.OverrideTypes+=['String255','String64k']
which will result in the COOL folder being created with the columns having maximum size of 255 characters and 64k characters. The default mapping for strings is set to 4k, for compatibility with COOL1.3.
Storing and registering conditions objects from Athena is normally done in two steps - first writing the objects out to a POOL/ROOT file using the AthenaOutputStreamTool, then writing the corresponding POOL object references to the IOV database using IOVRegistrationSvc. This can be done from user algorithms during execute or finalise. For doing 'trial' runs, typically only the objects are written out (allowing them to be read back in and verified using CondProxyProvider), and the registration step is skipped until the user knows the objects are correct.
The AthenaOutputStreamTool and IOVRegistrationSvc provide a lot of flexibility, but for simple situations (writing one or a few conditions data objects on finalize), the OutputConditionsAlg can be used, without the need to write any extra user code. This algorithm does nothing on execute, and on finalize first calls AthenaOutputStreamTool to write the conditions objects to a POOL file, then optinally registers them in the IOV database. The algorithm can be configured entirely from joboptions, typically as the last algorithm in the theApp.topAlg sequence (to ensure any user calibration algorithms producing conditions data objects have already finalized). A typical jobOption sequence would be:
from RegistrationServices.OutputConditionsAlg import OutputConditionsAlg myOCA=OutputConditionsAlg("BeamPosWriter",outputFile="mycondobjects.root", ObjectList=[ "AthenaAttributeList#/Indet/Beampos" ], WriteIOV=True,IOVTagList=["nominal"]) # further parameters can be set using the passed back algorithm instance myOCA.Run1=3 myOCA.LB1=3 myOCA.Run2=9999 myOCA.LB2=999999
# specify POOL converter package containing the converters for MyCondClass include ( "DetDescrCondAthenaPool/DetDescrCondAthenaPool_joboptions.py" )
The COOL database output is written to the default database connection, which is normally in a local SQLite file mycool.db. This can be changed using the IOVDbSvc.dbConnecction property if needed.
The OutputConditionsAlg has the following properties:
If WriteIOV is not set, only the output stream is written, without registration in the IOV database. The ObjectList is used to identify the conditions data objects to be written from the Transient Detector Store (TDS). Each entry in the list is either a classname, in which case the default instance of the class in Storegate TDS will be written, using the corresponding Storegate key as conditions database folder name; or an entry of the form 'classname::key' (e.g. AlignableTransform#/Indet/Align/SCT). This latter form is appropriate when several instances of the same object exist, and need to be written out to several folders. For example, the following joboption tells the tool to write out two MyCondObjects with seperate keys /MyCond/Obj1 and /MyCond/Obj2 to folders /MyCond/Obj1 and /MyCond/Obj2.
myOCA.ObjectList=[ "MyCondObject#/MyCond/Obj1", "MyCondObject#/MyCond/Obj2" ]
A third form 'classname::key::folder' can be used to override the default where the conditions DB folder is set to the same name as the Storegate key; for example the specification 'MyCondObject#/MyCond/Obj1#/MyCond/AlternateFolder' writes the object with key /MyCond/Obj1 to folder /MyCond/AlternateFolder. The AthenaOutputStream-like syntax "MyCondObject#*" to write ALL instances of MyCondObject does NOT work with this algorithm.
The IOVTagList should contain one tag for each entry in the ObjectList. If no (or an insufficient number) of tags are specified, the corresponding objects are not tagged (i.e. just visible in the HEAD of the conditions data.)
Note that CondMultiChanCollections (container objects with several references to different POOL objects, mapped to COOL folders with several channels) can also be written using this tool, by giving the container object name as the classname.
1.8.18