1 / 13

“Algorithm Tools” what they are, how to get them and how to use them

“Algorithm Tools” what they are, how to get them and how to use them. G.Corti 5th Software Week 6 July 2000. Algorithms and Services. Algorithms (and sub-Algorithms) are initialized and finalized by the framework

Download Presentation

“Algorithm Tools” what they are, how to get them and how to use them

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. “Algorithm Tools”what they are, how to get them and how to use them G.Corti 5th Software Week 6 July 2000

  2. Algorithms and Services • Algorithms (and sub-Algorithms) • are initialized and finalized by the framework • are executed once per event ( sub-algorithms depending on the parent algorithm ) • have the lifetime of a job • request/store/share data in Transient Event Store • Services • are used by the algorithms to help perform their work • are setup and initialized at the beginning of a job by the framework and used by many algorithms as often as necessary • they do not have a “state” G.Corti

  3. Simpler algorithms? • Sometimes in an Algorithm it is necessary to execute the same operation more than once per event, only for some events, on specific non identifiable data objects, producing new objects that will be put in the Event Store later • Vertexing • Track transport • Association to truth • Selection of particles based on a pID CL • Some Algorithms want to do similar operations but with a slightly different configuration, some will use a “standard configuration” Idea of Tools and ToolSvc G.Corti

  4. “Requirements” • An Algorithm requires a Tool on a per need base • The ToolSvc checks if the requested type of Tool is available and returns an instance of the requested type after configuring it • An Algorithm can have a private instance of a Tool that can be configured according to its need via JobOptions • An Algorithm can use a Tool “as-it-is”, in this case the ToolSvc will provide a “common” Tool (shared-Tool) • An Algorithm should be able to use a Sub-Tool without worrying about the implementation • The ToolSvc keeps track of the Tools instantiated and if a tool exists it does not re-create it • An Algorithm can tell the ToolSvc if it will not need a tool anymore • The ToolSvc will decide which tools instances can be deleted (always done at finalization of the Service) • Not only Algorithms would want to use Tools ( also Services … ) G.Corti

  5. IProperty ConcreteTool1 SubTool ConcreteTool2 AlgTool IService ToolSvc ConcreteAlgorithm ISubTool ToolFactory < T > Tools and ToolSvc diagram IToolSvc IAlgTool IToolFactory G.Corti

  6. The IAlgTool interface is implemented by the AlgTool base class name( ) std::string the identifying full name of an AlgTool instance concatenation of the parent name, a dot, and a tool dependent part ToolsAnalysisAlgorithm.ImpactPar tool dependent part automatically set to type or user specified type( ) std::string the type (concrete class) of an AlgTool parent ( ) const IInterface* the parent of a concrete AlgTool can be an algorithm or a service IAlgTool G.Corti

  7. The IToolSvc interface is the specific interface implemented by the ToolSvc retrieveTool (const std::string& type, T*& tool, const IInterface* parent=0, bool createIf=true ) StatusCode retrieve specified tool sub-type with tool dependent part of the name automatically assigned type, is the AlgTool type tool, returned as type requested by the user parent, by default no parent createIf, flag requesting creation or not if not existing, by default created retrieveTool (const std::string& type, const std::string& name, T*& tool, const IInterface* parent=0, bool createIf=true ) as above but with tool dependent part of the name specified by the requester as name IToolSvc G.Corti

  8. Some remarks • An AlgTool does not have an initialize/finalize method • The AlgTool base class has an accessor to the ServiceLocator and to the MessageService • the tool sets them at creation by getting them from the parent • specific services can be retrieved by derived tools if necessary • “Common Tool” or “Private Tool” • Common tools “belong” to the ToolSvc (when parent is not specified) • the full identifying name is for example ToolSvc.ImpactPar • If a common tool is requested the first request will trigger its creation • Private tool really belong to the parent but the parent does not need to keep them G.Corti

  9. ...remarks (cont.) • ToolSvc will “hold” a tool. At finalization it will clean up all the tools. • Example of how to use tools and some concrete implementations of tools in GaudiExamples/ToolsAnalysis of next Gaudi release • There could be GaudiTools, specific applications tools (ex. Physics analysis tools, user tools) G.Corti

  10. How to retrieve a tool • Get the ToolSvc ( as any other service ) IToolSvc* toolsvc = 0; sc = serviceLocator()->getService( "ToolSvc", IID_IToolSvc, (IInterface*&)( toolsvc )); • at the moment ToolSvc is an ExternalService • need to request it in the JobOptions • it is not available in the Algorithm service accessor methods • Retrieve a tool ImpactPar* impPar sc = toolsvc->retrieveTool("ImpactPar", impPar, this ) if( sc.isFailure() ) { log << MSG::FATAL << ”Unable to create tool" << endreq; return sc; } • the algorithm decides when and if to keep it or not G.Corti

  11. How to write a concrete tool • Instantiate a static factory in the implementation file static ToolFactory<VertexSmearer> s_factory; const IToolFactory& VertexSmearerFactory = s_factory; • Inherit from AlgTool base class • Could have an additional level of inheritance with additional interfaces • Declare in constructor specific properties and get services necessary to the implementation VertexSmearer::VertexSmearer(const std::string& type, const std::string& name, const IInterface* parent) : AlgTool( type, name, parent ) { m_randSvc = 0; if( serviceLocator() ) { StatusCode sc = serviceLocator()->getService( "RndmGenSvc", IID_IRndmGenSvc, (IInterface*&) (m_randSvc) ); } declareProperty("dxVtx", m_dxVtx = 9 * micrometer); • Implement necessary functionality G.Corti

  12. Configure a tool via the jobOptions • A concrete tool can be configured using the jobOptions • Same convention as for everything else: • IdentifyingNameOfTool.NameOfProperty • AlgTool base class has the OutputLevel Property • If not specified in the JobOptions the OutputLevel of the parent will be taken RecPrimaryVertex.VertexSmearer.OutputLevel = 3; RecPrimaryVertex.VertexSmearer.dxVtx = 0.009; RecPrimaryVertex.VertexSmearer.dyVtx = 0.009; RecPrimaryVertex.VertexSmearer.dzVtx = 0.038; G.Corti

  13. First version of the ToolSvc and AlgTool is available in GaudiSys v5 • Concrete tools can be implemented and used • More bookkeeping in the future • Additional inheritance level with more interfaces for general tools to be developed G.Corti

More Related