The central object managing the data processing. More...

#include <Process.h>

Collaboration diagram for fire::Process:

Public Member Functions
	Process (const config::Parameters &configuration)
	Construct the process by configuring the necessary objects. More...

	~Process ()
	close logging before we are done More...

void	run ()
	Do the processing run. More...

const EventHeader &	eventHeader () const
	Get a constant reference to the event header. More...

EventHeader &	eventHeader ()
	Get a non-constant reference to the event header. More...

const RunHeader &	runHeader () const
	Get a const reference to the run header. More...

RunHeader &	runHeader ()
	Get a non-const reference to the run header. More...

void	addStorageControlHint (StorageControl::Hint hint, const std::string &purpose, const std::string &processor)
	Add a storage control hint to the StorageControl system. More...

Conditions &	conditions ()
	Get a reference to the current conditions system. More...

Private Member Functions
void	newRun (RunHeader &rh)
	Method to declare a new run is beginning. More...

bool	process (const std::size_t &n_events_processed)
	process the event More...

	ENABLE_LOGGING (Process)
	log through the 'Process' channel

Private Attributes
int	event_limit_
	limit on number of events to process

int	log_frequency_
	frequency with which event info is printed

int	max_tries_
	number of attempts to make before giving up on an event PRODUCTION MODE

int	run_
	run number to use PRODUCTION MODE

std::vector< std::string >	input_files_
	input file listing, PRODUCTION MODE if empty

io::Writer	output_file_
	output file we are writing to

std::vector< std::unique_ptr< Processor > >	sequence_
	the sequence of processors to run

StorageControl	storage_control_
	object used to determine if an event should be saved or not

std::unique_ptr< Conditions >	conditions_
	handle to conditions system

Event	event_
	event object

RunHeader *	run_header_
	the current run header

Detailed Description

The central object managing the data processing.

Constructor & Destructor Documentation

◆ Process()

fire::Process::Process ( const config::Parameters & configuration )

Construct the process by configuring the necessary objects.

The order with which we configure the objects is very important. Some objects require references to other objects (for example, Event depends on an h5::Writer), so the order the objects are declared and therefore the order in which they are constructed should be modified with care.

Currently, the order of construction is given below. I skip listing any types provided by STL.

The output file as a h5::Writer
the Event bus
StorageControl system

After these initial constructions, the logging is opened.

Note: The user conditions providers are constructed before logging is open. This will cause some funky behavior is the user attempts to log messages in their conditions provider constructors.

After the logging is opened, we go through the registered libraries and use factory::loadLibrary to load them dynamically. These libraries provide the complete list of registered conditions providers and processors, so we then construct the conditions system and the sequence of processors (in order).

Exceptions

Exception if there is no sequence and the configuration does not have a parameter named 'testing' set to true.

See also: factory::loadLibrary for how libraries are dynamically loaded; Conditions::Conditions for how providers are created; factory::Factory::make for how processors and providers are made; logging::open for how the logging is initialized

Parameters

[in] configuration complete processing configuration

◆ ~Process()

fire::Process::~Process ( )

close logging before we are done

This closes up the logging that we opened in the constructor.

Member Function Documentation

◆ addStorageControlHint()

void fire::Process::addStorageControlHint	(	StorageControl::Hint	hint,
		const std::string &	purpose,
		const std::string &	processor
	)

inline

Add a storage control hint to the StorageControl system.

See also: StorageControl::addHint for how these hints are used; Processor::setStorageHint for how user Processors are supposed to call this function.

Parameters

[in]	hint	hint to storage on what to do with this event
[in]	purpose	reason for this hint
[in]	processor	processor from which this hint came from

◆ conditions()

Conditions & fire::Process::conditions ( )

inline

Get a reference to the current conditions system.

Since the conditions system is constructed in the Process constructor, we don't use any assertions to check the validty of that pointer.

Returns: reference to conditions system

◆ eventHeader() [1/2]

EventHeader & fire::Process::eventHeader ( )

inline

Get a non-constant reference to the event header.

Returns: reference to event header

◆ eventHeader() [2/2]

const EventHeader & fire::Process::eventHeader ( ) const

inline

Get a constant reference to the event header.

Returns: const reference to event header

◆ newRun()

void fire::Process::newRun ( RunHeader & rh )

private

Method to declare a new run is beginning.

We update the pointer to the run header to use the passed reference. This is so asynchronous callers can access the run header via Process.

Then we call the following user call backs in order.

This allows the user to have access to the run header both before and after the conditions system accesses it.

See also: Processor::beforeNewRun for base method to user processors; Processor::onNewRun for base method to user processors; Conditions::onNewRun for what the conditions system does

Parameters

[in] rh RunHeader for new run to be processed

◆ process()

bool fire::Process::process ( const std::size_t & n_events_processed )

private

process the event

If the event is not aborted, the storage controller is given the choice on whether the event should be kept. If it decides to "keep" the event, then the event is saved to the output file

We first reset the event state via StorageControl::resetEventState and then we go through the processors in order. If any of the processors abort the event, we return false, otherwise we check with the storage system on whether this event should be kept. Before leaving and after saving, we call Event::next to move the event bus to the next event.

See also: Event::save for how the event saves in-memory objects to disk; StorageControl::keepEvent for how the keep decision is made

Parameters

[in] n_events_processed number of events we have already processed only used for printing out a status message

Returns: true if event was successfully processed (i.e. not aborted)

◆ run()

void fire::Process::run ( )

Do the processing run.

Production Mode

This is when no input files are provided.

We simply do max_tries_ number of attempts for event_limit_ number of events looping through the processor sequence. This is helpful for simulations where aborted events are a common method to generate samples focused on specific interactions.

The run header and event headers are updated with their time stamps and using run_ to define the run number.

Reconstruction Mode

This is when there are input files provided.

The number of events processed is the number of events in the input file(s) or the event_limit_ if it is provided and lower than the number in the input files.

All of the run headers from the input files are loaded into an in-memory cache which is then dumped to the output file at the end of processing all input files.

The event headers are loaded from the input files in the same manner as other event objects.

See also: newRun for how new runs are handled; process for how individual events are processed

the cache of runs from the opened input files

Load runs into in-memory cache

◆ runHeader() [1/2]

RunHeader & fire::Process::runHeader ( )

inline

Get a non-const reference to the run header.

Note: We use assert to make sure the run header is defined before de-referencing the pointer we have.

Returns: reference to run header

◆ runHeader() [2/2]

const RunHeader & fire::Process::runHeader ( ) const

inline

Get a const reference to the run header.

Note: We use assert to make sure the run header is defined before de-referencing the pointer we have.

Returns: const reference to run header

The documentation for this class was generated from the following files:

include/fire/Process.h
src/fire/Process.cxx

Public Member Functions

Private Member Functions

Private Attributes

Detailed Description

Constructor & Destructor Documentation

◆ Process()

◆ ~Process()

Member Function Documentation

◆ addStorageControlHint()

◆ conditions()

◆ eventHeader() [1/2]

◆ eventHeader() [2/2]

◆ newRun()

◆ process()

◆ run()

Production Mode

Reconstruction Mode

◆ runHeader() [1/2]

◆ runHeader() [2/2]