CMS 3D CMS Logo

 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Groups Pages
List of all members | Public Member Functions | Private Attributes
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.

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.

Currently, the product types are not used as products and all data is passed through the edm::Service<DQMStore>.

Definition at line 279 of file MonitorElementCollection.h.

Member Function Documentation

auto MonitorElementCollection::begin ( void  ) const
inline

Definition at line 291 of file MonitorElementCollection.h.

References data_.

291 { return data_.begin(); }
std::vector< std::unique_ptr< const MonitorElementData > > data_
auto MonitorElementCollection::end ( void  ) const
inline

Definition at line 293 of file MonitorElementCollection.h.

References data_.

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

293 { return data_.end(); }
std::vector< std::unique_ptr< const MonitorElementData > > data_
bool MonitorElementCollection::mergeProduct ( MonitorElementCollection const &  product)
inline

Definition at line 295 of file MonitorElementCollection.h.

References cms::cuda::assert().

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

Definition at line 283 of file MonitorElementCollection.h.

References cms::cuda::assert(), data_, eostools::move(), and relativeConstraints::value.

283  {
284  // enforce ordering
285  assert(data_.empty() || data_[data_.size() - 1] <= value);
286  data_.push_back(std::move(value));
287  }
assert(be >=bs)
def move
Definition: eostools.py:511
std::vector< std::unique_ptr< const MonitorElementData > > data_
void MonitorElementCollection::swap ( MonitorElementCollection other)
inline

Definition at line 289 of file MonitorElementCollection.h.

References data_.

289 { data_.swap(other.data_); }
std::vector< std::unique_ptr< const MonitorElementData > > data_

Member Data Documentation

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

Definition at line 280 of file MonitorElementCollection.h.

Referenced by begin(), end(), push_back(), and swap().