1 / 12

DST User Interface CPT Week, CERN November 1st, 2004

DST User Interface CPT Week, CERN November 1st, 2004. Norbert Neumeister. Introduction. DST: Store the result of event reconstruction Event reconstruction is very CPU intensive Provide compact information for analysis A set of homogeneous collections of RecObjects User Interface:

amos
Download Presentation

DST User Interface CPT Week, CERN November 1st, 2004

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. DSTUser InterfaceCPT Week, CERNNovember 1st, 2004 Norbert Neumeister

  2. Introduction • DST: • Store the result of event reconstruction • Event reconstruction is very CPU intensive • Provide compact information for analysis • A set of homogeneous collections of RecObjects • User Interface: • RecQuery • RecCollection • FilteredRecCollection Norbert Neumeister

  3. RecCollections • RecCollection addresses the off-line analysis use case: iterating over reconstructed objects of some type and using them for analysis or for further reconstruction of higher-level objects. • The collection is homogeneous: All objects in the collection are reconstructed in the same way • Within the event • In all events • Reproducibly • Reconstruction is “expensive” and should not be wasted: • Reconstruction is done “on demand” • Reconstruction results are cached for further access • Reconstruction results are made persistent if desired: RecAlgoName:Persistent = true Norbert Neumeister

  4. RecCollection • A RecCollection ”reconstructs” objects of type T when dispatched an event of type RecEvent. It provides a collection of RecObj T in the current event. • RecCollection is a LazyObserver of RecEvent: • not reconstructed when dispatched, but only when asked for content • Consequence: • RecCollections which are instantiated but not used "don't cost" • STL vector like interface:begin(), end(), size(), empty(), front(), back(), … MyRecObj inherits from RecObj RecCollection<MyRecObj> myobjects(RecQuery("Name_of_algorithm“)); cout << myobjects.size() << endl; cout << myobjects.config() << endl; cout << myobjects.exists() << endl; RecCollection<MyRecObj>::const_iterator it; Norbert Neumeister

  5. RecCollection RecQuery q("TrackReconstructor"); RecCollection<Track> c(q); const Track& t1 = c.front(); const Track& t2 = c[2]; RecCollection<Track>::Range r = c.range(); typedef RecCollection<Track>::const_iterator RI; for ( RI i = r.first; i != r.second; ++i ) { const Track& track = *i; cout << track << endl; } cout << c.name() << " : " << c.exists() << endl; cout << c.config() << endl; if ( !c.empty() ) cout << c.size() << endl; Norbert Neumeister

  6. Algorithm Configuration • The configuration is decomposed into • Algorithm name • Version identifier • Fixed parameters directly used by the algorithm • Do not depend on the input data • If they change the reconstruction result changes • Modeled by ParameterSet • Calibration parameters directly used by the algorithm • Depend on the input data • If they change the reconstruction result changes • Modeled by CalibrationSet • Configuration of the input RecCollections (components) • Modeled by ComponentSet • All these compose theRecConfig Norbert Neumeister

  7. RecQuery • User-friendly way to define RecConfigs • Only the algorithm name is mandatory • All other fields are taken from the default Config • Only the parameters, components, or calibrations which need to be changed (or fixed) need to be set • You don't have to know the names of all parameters, only the ones you want to modify • You can put anything in a RecQuery, e.g. Parameter names not known to the RecAlgorithm • The check will be done when you usethe RecQuery, and an exception will be thrown if it's not OK • Some parameter type conversions are accepted and done automatically • int to double Norbert Neumeister

  8. RecQuery • RecQuery is the user interface class to query for reconstructed objects. It provides a user-friendly way to define a RecConfig. Only the algorithm name is mandatory, all other fields of the RecConfig are taken from the default configuration. It allows to modify only the parameters, components or calibrations which need to be changed. For all other parameters, components and calibrations the default values are used. • Changing parameters: • Changing components: RecQuery q("AlgorithmName"); or RecQuery q("AlgorithmName", "Version"); RecQuery q("AlgorithmName"); q.setParameter("ConeSize", 0.77); RecQuery q("AlgorithmName","1.0"); RecQuery myTF("TrackFinder"); q.setComponent("TrackReconstructor", myTF); Norbert Neumeister

  9. FilteredRecCollection • FilteredRecCollection is a drop-in replacement for RecCollection that adds filtering (selection) of the elements. It takes, in addition to the RecQuery argument, also a Filter<T> argument. The caller must make sure that the filter instance is not deleted during the lifetime of the FilteredRecCollection. The usual methods begin(), end(), range() and size(), etc. refer to the filtered subset of RecObjects. RecQuery q("TrackReconstructor","1.0"); Capri::Filter f; FilteredRecCollection<Track> c(q,f); FilteredRecCollection<Track>::Range r = c.range(); FilteredRecCollection<Track>::const_iterator RI; for ( RI i = r.first; i != r.second; ++i ) { const Track& track = *i; cout << track << endl; } cout << c.size() << endl; cout << c.config() << endl; Norbert Neumeister

  10. ReadOnly Mode Adding the line RecAlgoName:Request = ReadOnly to the “.orcarc” file will change the behavior of a RecCollection. In this mode only objects which are already stored in a dataset can be read and the reconstruction on-demand mechanism is switched off. In case the requested collection is not stored in the dataset, a warning will show up. • ReadOnly affects the RecCollection, and all components automatically: • If one asks for ReadOnly BJets, they will refer to the ReadOnly TTracks and ReadOnlyCaloWhatevers. • Other RecQueries for TTrack (not via BJets) will not be affected by this: • CombinatorialTrackFinder:Request can be Auto, and user RecCollections for TTrack may be re-reconstructed. Norbert Neumeister

  11. ReadOnly Mode • There is an important difference between ReadOnly and Auto when reading DSTs: • If the RecCollection is present on the DST and is read in Auto mode, it will be checked against the CURRENT version of the algorithm, and if the current version of ORCA has a different version of the algorithm the persistent collection will not be used and reconstruction will occur. • The logic of Auto is "same results as if reconstructing now". If one reads in ReadOnly, the user query is expanded against the PERSITENT default config, i.e. against the version of the algorithm used for writing. So the persistent collection will be read back even if the current ORCA has different version of the algorithm. Norbert Neumeister

  12. RecConfig Settings Order of initialization: 1) defaultConfig of the algorithm • That’s the only place where parameter names and types are defined 2) .orcarc: Every parameter is configurable with the following syntax • AlgorithmName:ParameterName = value • overwrites 1) 3) The current RecQuery overwrites 2) For components same sequence as for parameters in a recursive way: AlgorithmName:ComponentName:ParameterName = value The most qualified line has precedence, i.e. CombinatorialTrackFinder:SeedGenerator:ptCut = 1.2 overrides GlobalPixelSeedGenerator:ptCut = 2.0 Norbert Neumeister

More Related