MonitorElementCollection Class Reference

#include "DataFormats/Histograms/interface/MonitorElementCollection.h"

Public Member Functions
auto	begin () const
auto	end () const
bool	mergeProduct (MonitorElementCollection const &product)
void	push_back (std::unique_ptr< const MonitorElementData > value)
void	swap (MonitorElementCollection &other)

Private Attributes
std::vector< std::unique_ptr< const MonitorElementData > >	data_

Detailed Description

Description: Product to represent DQM data in LuminosityBlocks and Runs. The MonitorElements are represented by a simple struct that only contains the required fields to represent a ME. The only opration allowed on these objects is merging, which is a important part of the DQM functionality and should be handled by EDM. Once a MonitorElement enters this product, it is immutable. During event processing, the ROOT objects need to be protectd by locks. These locks are not present in this structure: Any potential modification needs to be done as a copy-on-write and create a new MonitorElement. The file IO for these objects should still be handled by the DQMIO classes (DQMRootOutputModule and DQMRootSource), so persistent=false would be ok for this class. However, if we can get EDM IO cheaply, it could be useful to handle corner cases like MEtoEDM more cleanly.

Usage: This product should only be handled by the DQMStore, which provides access to the MEs inside. The DQMStore will wrap the MonitorElementData in real MonitorElements, which allow various operations on the underlying histograms, depending on the current stage of processing: In the RECO step, only filling is allowed, while in HARVESTING, the same data will be wrapped in a MonitorElement that also allows access to the ROOT objects. We only use pointers to MonitorElementData, to allow replacing it with a variable-size templated version later. That could eliminate one level of indirection in accessing histograms.

Definition at line 184 of file MonitorElementCollection.h.

Member Function Documentation

auto MonitorElementCollection::begin ( void  ) const

inline

Definition at line 196 of file MonitorElementCollection.h.

{ return data_.begin(); }

auto MonitorElementCollection::end ( void  ) const

inline

Definition at line 198 of file MonitorElementCollection.h.

Referenced by Types.LuminosityBlockRange::cppID(), and Types.EventRange::cppID().

{ return data_.end(); }

bool MonitorElementCollection::mergeProduct ( MonitorElementCollection const &  product )

inline

Definition at line 200 of file MonitorElementCollection.h.

                                                             {
    // discussion: https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuidePerRunAndPerLumiBlockData#Merging_Run_and_Luminosity_Block
    assert(!"Not implemented yet.");
    return false;
    // Things to decide:
    // - Should we allow merging collections of different sets of MEs? (probably not.) [0]
    // - Should we assume the MEs to be ordered? (probably yes.)
    // - How to handle incompatible MEs (different binning)? (fail hard.) [1]
    // - Can multiple MEs with same (dirname, objname) exist? (probably yes.) [2]
    // - Shall we modify the (immutable?) ROOT objects? (probably yes.)
    //
    // [0] Merging should increase the statistics, but not change the number of
    // MEs, at least with the current workflows. It might be convenient to
    // allow it, but for the beginning, it would only mask errors.
    // [1] The DQM framework should guarantee same booking parameters as long
    // as we stay within the Scope of the MEs.
    // [2] To implement e.g. MEs covering blocks of 10LS, we'd store them in a
    // run product, but have as many MEs with same name but different range as
    // needed to perserve the wanted granularity. Merging then can merge or
    // concatenate as possible/needed.
    // Problem: We need to keep copies in memory until the end of run, even
    // though we could save them to the output file as soon as it is clear that
    // the nexe LS will not fall into the same block. Instead, we could drop
    // them into the next lumi block we see; the semantics would be weird (the
    // MEs in the lumi block don't actually correspond to the lumi block they
    // are in) but the DQMIO output should be able to handle that.
  }

void MonitorElementCollection::push_back ( std::unique_ptr< const MonitorElementData >  value )

inline

Definition at line 188 of file MonitorElementCollection.h.

References eostools::move(), and relativeConstraints::value.

                                                                {
    // enforce ordering
    assert(data_.empty() || data_[data_.size() - 1] <= value);
    data_.push_back(std::move(value));
  }

void MonitorElementCollection::swap ( MonitorElementCollection &  other )

inline

Definition at line 194 of file MonitorElementCollection.h.

References data_.

{ data_.swap(other.data_); }

Member Data Documentation

std::vector<std::unique_ptr<const MonitorElementData> > MonitorElementCollection::data_

private

Definition at line 185 of file MonitorElementCollection.h.

Referenced by swap().