Athena Developer Guide

More documents

Recommendations

Info

$' \^' I$

<strong>Athena</strong> Chapter 2 The framework architecture Version/Issue: 2.0.0 ISvcLocator ApplicationManager EventDataService IDataProviderSvc IAlgorithm IProperty DetectorDataService HistogramService IDataProviderSvc IHistogramSvc ConcreteAlgorithm MessageService IMessageSvc ObjectA ObjectB ParticlePropertySvc IParticlePropertySvc Figure 2.1 The main components of the framework as seen by an algorithm object. Each of these services is provided by a component and the use of these components is via an interface. The interface used by algorithm objects is shown in the figure, e.g. for both the event data and detector data stores it is the IDataProviderSvc interface. In general a component implements more than one interface. For example the event data store implements another interface: IDataManager which is used by the application manager to clear the store before a new event is read in. An algorithm’s access to data, whether the data is coming from or going to a persistent store or whether it is coming from or going to another algorithm is always via one of the data store components. The IDataProviderSvc interface allows algorithms to access data in the store and to add new data to the store. It is discussed further in Chapter 7 where we consider the data store components in more detail. page 16 The histogram service is another type of data store intended for the storage of histograms and other “statistical” objects, i.e. data objects with a lifetime of longer than a single event. Access is via the IHistogramSvc which is an extension to the IDataProviderSvc interface, and is discussed in Chapter 11. The n-tuple service is similar, with access via the INtupleSvc extension to the IDataProviderSvc interface, as discussed in Chapter 12.
<strong>Athena</strong> Chapter 2 The framework architecture Version/Issue: 2.0.0 In general an algorithm will be configurable: It will require certain parameters, such as cut-offs, upper limits on the number of iterations, convergence criteria, etc., to be initialised before the algorithm may be executed. These parameters may be specified at run time via the job options mechanism. This is done by the job options service. Though it is not explicitly shown in the figure this component makes use of the IProperty interface which is implemented by the Algorithm base class. During its execution an algorithm may wish to make reports on its progress or on errors that occur. All communication with the outside world should go through the message service component via the IMessageSvc interface. Use of this interface is discussed in Chapter 13. As mentioned above, by virtue of its derivation from the Algorithm base class, any concrete algorithm class implements the IAlgorithm and IProperty interfaces, except for the three methods initialize(), execute(), and finalize() which must be explicitly implemented by the concrete algorithm. IAlgorithm is used by the application manager to control top-level algorithms. IProperty is usually used only by the job options service. The figure also shows that a concrete algorithm may make use of additional objects internally to aid it in its function. These private objects do not need to inherit from any particular base class so long as they are only used internally. These objects are under the complete control of the algorithm object itself and so care is required to avoid memory leaks etc. We have used the terms “interface” and “implements” quite freely above. Let us be more explicit about what we mean. We use the term interface to describe a pure virtual C++ class, i.e. a class with no data members, and no implementation of the methods that it declares. For example: class PureAbstractClass { virtual method1() = 0; virtual method2() = 0; } is a pure abstract class or interface. We say that a class implements such an interface if it is derived from it, for example: class ConcreteComponent: public PureAbstractClass { method1() { } method2() { } } A component which implements more than one interface does so via multiple inheritance, however, since the interfaces are pure abstract classes the usual problems associated with multiple inheritance do not occur. These interfaces are identified by a unique number which is available via a global constant of the form: IID_InterfaceType, such as for example IID_IDataProviderSvc. Using these it is possible to enquire what interfaces a particular component implements (as shown for example through the use queryInterface() in the finalize() method of the SimpleAnalysis example). page 17
Page 1 and 2: ATLAS Athena The ATLAS Common Frame
Page 3 and 4: Athena Table of Contents Version/Is
Page 9 and 10: Athena Chapter 1 Introduction Versi
Page 11 and 12: Athena Chapter 1 Introduction Versi
Page 13 and 14: Athena Chapter 2 The framework arch
Page 15: Athena Chapter 2 The framework arch
Page 19 and 20: Athena Chapter 3 Release notes Vers
Page 21 and 22: Athena Chapter 4 Establishing a dev
Page 23 and 24: Athena Chapter 5 Writing algorithms
Page 35 and 36: Athena Chapter 6 Scripting Version/
Page 43 and 44: Athena Chapter 7 Accessing data Ver
Page 55 and 56: Athena Chapter 8 StoreGate - the ev
Page 67 and 68:
Athena Chapter 8 StoreGate - the ev
Page 69 and 70:
Athena Chapter 9 Data dictionary Ve
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Athena Chapter 10 Detector Descript
Page 77 and 78:
Athena Chapter 11 Histogram facilit
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Athena Chapter 12 N-tuple and Event
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Athena Chapter 13 Framework service
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Athena Chapter 14 Tools and ToolSvc
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Athena Chapter 15 Converters Versio
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Athena Chapter 16 Visualization Ver
Page 149 and 150:
Athena Chapter 17 Physical design i
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Athena Chapter 18 Framework package
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Athena Chapter 19 Analysis utilitie
Page 171 and 172:
Athena Version/Issue: 2.0.0 Appendi
Page 173 and 174:
Athena Appendix B Options for stand
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Athena Appendix C Design considerat
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Athena Version/Issue: 2.0.0 Appendi
Page 189 and 190:
Athena Version/Issue: 2.0.0 19.6.6
Page 191 and 192:
Athena Version/Issue: 2.0.0 A AIDA
Page 193 and 194:
Athena Version/Issue: 2.0.0 of N-tu
Page 195:
Athena Version/Issue: 2.0.0 ROOT 17
show all

Athena Developer Guide

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?