fire v0.19.0
Framework for sImulation and Reconstruction of Events
|
Container and cache for conditions and conditions providers. More...
#include <Conditions.h>
Classes | |
struct | CacheEntry |
An entry to store an already loaded conditions object. More... | |
Public Member Functions | |
Conditions (const config::Parameters &ps, Process &p) | |
Configure the conditions system and attach the current process. More... | |
const ConditionsObject * | getConditionPtr (const std::string &condition_name) |
Core request action for a conditions object. More... | |
template<class ConditionType > | |
const ConditionType & | get (const std::string &condition_name) |
Primary request action for a conditions object. More... | |
ConditionsIntervalOfValidity | getConditionIOV (const std::string &condition_name) const |
Access the interval of validity for the given condition. More... | |
void | onProcessStart () |
Calls onProcessStart for all instances of ConditionsProvider. | |
void | onProcessEnd () |
Calls onProcessEnd for all instances of ConditionsProvider. | |
void | onNewRun (RunHeader &rh) |
Calls onNewRun for all instances of ConditionsProvider. More... | |
Private Attributes | |
Process & | process_ |
Handle to the Process. More... | |
std::map< std::string, std::shared_ptr< ConditionsProvider > > | providers_ |
Map of who provides which condition. | |
std::map< std::string, CacheEntry > | cache_ |
Conditions cache. | |
Container and cache for conditions and conditions providers.
This class and the classes in its immediate ecosystem (ConditionsProvider, ConditionsObject, and ConditionsIntervalOfValidity) are helpful for defining a "condition system". As the name implies, this system provides information about the conditions or circumstances in which a particular event's data was taken. For example, if we are taking data using a device that depends on the temperature, we would want to record the temperature that a certain series of events were taken at.
Since (most of the time) conditions information is changing slowly relative to the events (i.e. we expect one piece of conditions information to be valid for many events in a row), this system is separate from the Event which holds the data.
The Conditions system holds all registered instances of ConditionsProvider in memory, waiting for a Processor to request a specific condition. If a provider that can provide the requested condition is available, the system caches that provider and returns the object that it provides. The system also requres instances of ConditionsProvider to define the range of validity that the condition can be used for so that the system can automatically update the condition when events with different conditions are encountered. This design makes it safe and efficient for a Processor to use Processor::getCondition on every event since this will only cause the construction of a new object on events where the conditions change according to their changing validity.
A reasonable question to ask is why even have a separation between providers and objects? The answer is because many of the provided objects could be memory intensive (for example, a big table of read out chip settings to be used for later reconstruction of the data), so having this memory only used when specifically requested makes the system easier and safer to use.
Users of fire will inevitably want to define their own conditions with their own providers. Conditions are defined simply by deriving from ConditionsObject so that the system can cache them. Providers are defined similarly as how a Processor is defined: deriving from the parent class ConditionsProvider and declaring it using a macro in the source file.
A more thorough example of definine your own conditions provider is given in the documentation of ConditionsProvider.
fire::Conditions::Conditions | ( | const config::Parameters & | ps, |
Process & | p | ||
) |
Configure the conditions system and attach the current process.
This is where the registered instances of ConditionsProvider are constructed.
Exception | if two registerned providers provide the same condition. |
[in] | ps | config::Parameters to configure |
[in] | p | handle to current Process |
|
inline |
Primary request action for a conditions object.
This is a small wrapper around getConditionPtr which does the necessary type conversion.
Exception | if requested condition object cannot be converted to the requested type |
T | type to cast condition object to |
[in] | condition_name | name of condition to retrieve |
ConditionsIntervalOfValidity fire::Conditions::getConditionIOV | ( | const std::string & | condition_name | ) | const |
Access the interval of validity for the given condition.
[in] | condition_name | name of condition to get IOV for |
const ConditionsObject * fire::Conditions::getConditionPtr | ( | const std::string & | condition_name | ) |
Core request action for a conditions object.
If the object is in the cache and still valid (IOV), the cached object will be returned. If it is not in the cache, or is out of date, the ConditionsProvider::getCondition method will be called to provide the object.
Exception | if condition object or provider for that object is not found. |
[in] | condition_name | name of condition to retrieve |
if still valid, we return what we have
void fire::Conditions::onNewRun | ( | RunHeader & | rh | ) |
Calls onNewRun for all instances of ConditionsProvider.
[in] | rh | current RunHeader |
|
private |
Handle to the Process.
We need this so we can provide it to all instances of ConditionsProvider and use it to obtain a handle to the current event header.