Requests for information about the detector are sent from the Detector User Interface (see
det::Detector) to a collection of so-called managers, each of which is designed to deal with a particular data format. A manager is a class which inherits from the
det::VManager interface class, and implements the purely virtual data retrieval methods defined in
det::VManager.Once a manager locates the requested data, it returns it to the user interface, where it is internally cached so that if another request is made for the same data, it can be more quickly retrieved. The user interface may also perform some simple analysis and/or packaging of the data in to a convenient object before returning it to the interface. Managers are collected into
det::ManagerRegister's, which are also concrete implementations of
det::VManager.The figure below illustrates the general idea. The left side of the figure depicts the hierarchy of objects in the Detector user interface. These objects relay requests for data to a registry of managers (right) which handle multiple data sources and formats. The small plug labeled "Manager Interface" represents the
det::VManager interface class.
Currently there are three different ManagerRegister's in the Offline software:
To activate a manager in one of the
det::ManagerRegister's above, one has to include its name in the appropriate
det::ManagerRegister configuration file. For example, the Fluorescence Detector MangerRegister configuration file contains a list of manager names:
<FDetectorManagerList>
<manager> FdChannelMappingManager </manager>
<manager> FdAlwaysUpManager </manager>
<manager> FTelescopeListXMLManager </manager>
<manager> FModelsXMLManager </manager>
<manager> FCalibSQLManager </manager>
</FDetectorManagerList>
ManagersRegisters implement a "Chain of responsibility". This means when a request for data is sent to a
det::ManagerRegister, each manager in the list is given the opportunity to respond to the request in the order the managers are listed in the configuration file. With this approach, it is possible to implement more than one manager for a particular sort of data. The manager appearing first in the
det::ManagerRegister configuration will take precedence over the manager appearing later. In this way, a special manager can override data from a general manager. For example, a user can decide to use a database for the majority of the description of the detector, but override some data by writing them in an XML file which is interpreted by the special manager. To give a concrete example, if one wanted to replace the calibration constants returned by the
fdet::FCalibSQLManager for a particular telescope, one could write a special manager called, say FCalibOverrideManager, and then include it in the FDetectorMangerList in a position before the
fdet::FCalibSQLManager:
<FDetectorManagerList>
<manager> FdChannelMappingManager </manager>
<manager> FdAlwaysUpManager </manager>
<manager> FTelescopeListXMLManager </manager>
<manager> FModelsXMLManager </manager>
<manager> FCalibOverrideManager </manager>
<manager> FCalibSQLManager </manager>
</FDetectorManagerList>
You can find the names of the default
det::ManagerRegister config files by looking in the default bootstrap files:
path_to_offline_install/share/auger-offline/config/standardFdIdealDetConfig.xml
path_to_offline_install/share/auger-offline/config/standardFdRealDetConfig.xml
path_to_offline_install/share/auger-offline/config/standardSdIdealDetConfig.xml
path_to_offline_install/share/auger-offline/config/standardSdRealDetConfig.xml
In these files, you will find a configLink for the three managers mentioned above, with configLink id's called SManagerRegister, FManagerRegister and AManagerRegister. The SManagerRegister link can be found in the SD configuration file. Both F- and AManagerRegister are referenced in the FD configuration.See the fwk::CentralConfig for more information about configLinks and bootstrap files.